#orclAPEX Security check list: #1 - Monitoring

Knowing who did what and when in an application helps in investigating unauthorized access.

Proactive workspace monitoring helps us to detect security incidents early and provides forensic evidence when breaches occur. Without it, security issues may persist undetected until significant damage has occurred. 

Let's see how we can do this in Oracle APEX.

Where to find Monitor Activity and how to configure it

Oracle APEX has a build-in feature for this: the  Monitor Activity. It is turned on by default. 

An workspace administrator can configure it at workspace level, accessing Manage Instance -> Feature Configuration -> Monitoring. 

If the Application Activity Logging is set to Use Application Settings then we can turn monitoring on or off for each individual application within workspace: go to Application Definitions -> Property to enable or disable logging.

The retention interval for audit information is set by default to 14 days but this can also be changed by a workspace administrator in the instance settings under Manage Instance  -> Manage Log Interval.

The maximum value that can be specified for retention interval is 180 days. If we need to keep the audit information for a longer period of time, we have to save it in local tables

View Audit Information

APEX provides 2 dashboards with audit information: one is available Administration Services (a) and monitor activity of all worspaces; teh second one is available in APEX Builder (b) and monitor activity within a workspace.

a) Administration Service -> Monitor Activity gives us access to reports on applications, developers, session activity in all workspaces. 

b) The Monitor Activity within a workspace provides reports that show developer activity, track page views, active sessions, login attempts and analysis reports. 

It's very easy to view the monitor reports within a workspace, if we have the APEX Builder installed: just click on the upper-right icon-menu Administration: 

Each report has an (almost) self-explanatory name; when in doubt, we always have the documentation :). 

What about production environment, where, from security reason, we should not have APEX Builder installed.  What to do in this case?

How to view audit information when APEX Builder is not available

APEX views are our friends, we should know them well, isn't it ? Depending on which kind of audit information we need, we can query the following 3 views: the APEX_WORKSPACE_ACCESS_LOG for records on login attempt; the APEX_WORKSPACE_ACTIVITY_LOG for records who is viewing which page; the APEX_WORKSPACE_SESSIONS for records on Oracle APEX sessions.

We can easily create our own dashboard and reports with the useful information from these 3 views. We can go one step further: find anomalies pattern, define report(s) for these and automatically email these report(s) to the responsible team. How to do this - it's a topic for a future post.

Conclusion

Monitoring workspace activity in Oracle APEX helps identify suspicious behavior patterns like, for example: unusual login times or locations, excessive failed login attempts, abnormal page access sequences. These patterns can indicate compromised accounts or insider threats before they cause significant damage.

We can use Monitor Activity within Workspace or create our own dashboard on audit information, Regular monitoring of these dashboards and sending automatic alerts on specific security-relevant events  is essential for maintaining security awareness and quickly identifying potential security incidents before they cause significant damage.

Oracle APEX Build Options: the what and the hows

In my department, we frequently have multiple teams working simultaneously on 2-3 features within the same APEX application, with each feature scheduled for release at different times. This results in maintaining multiple versions of the application across different environments. In the past, I've observed that teams often use Server-side Conditions to control feature visibility - specifically, APEX objects are hidden or shown based on the environment name (like DEV or TEST). I've show my colleagues that there is a better way to achieve the same result: using the Build Options and now everyone is using it.

What is this Build Options about?

It is an Oracle APEX feature that allows to conditionally include or exclude application components and functionality. One application can have as many Build Option as we want but only one can be assigned to a specific component or functionality.

We create / update /remove Build Options in Shared Components 🠆Application Logic 🠆 Build Options

 

Every Build Option we create must have a:

Name  - should be meaningful for the purpose

Status -  is referring to how the component is consider in an environment. It has two possible values: Include - meaning that the Application Express engine recognizes it as part of the application definition during runtime - and Exclude - meaning that the Application Express engine treats it as if it did not exist.  

Default on export – is the status to be consider when application is exported and then imported in another environment. 

On Upgrade Keep Status – indicate what is happening when the application is upgraded: Yes - build option status in the deployed application should be kept, No – build status is overwritten with the specified status when the application is upgraded. 

Application components and functionalities can be associated to a specific Build Option using ‘Configuration’:

 

The following components support Build configuration: Pages, Regions, Items (applications or page), Buttons, Menu entries, Processes (applications or page), Dynamic actions, List of Values

    Note: Pre-APEX 23.x: List of Values did not support Build configurations.

Starting with APEX 23.x, there is a special Build Options named Comment Out, included by default in every new APEX application. We use Comment Out for the elements we want to exclude for good from application but we don't want to delete them yet. This is a very useful replacement of the Server-side condition "Never".

Comment Out is available in Configuration, Build Option list, and also in the context menu of a component. 

 

  For a component "Commented Out" we can simply revert the setting with the "Uncomment" option.

 

Note 1: I did mentioned above that every new application created in APEX 23.x or above has the Comment Out created automatically. For applications created prior to APEX 23.1 the upgrade to a newer APEX version do not create automatically this Build Option. There is a simple trick we can do, to benefit the feature in applications developed in an older APEX version: we simply create a Build Option with the name "Commented Out" (pay attention at spelling!) and ...boom...the option appears like magic in the context menu. 

Don't forget to set the correct status (exclude), the default setting to exclude on export and not to keep status on upgrade, as below:

 Note 2: If an APEX component, configured with an Exclude Build Options, is referring a database object then the database object may not exist in the environment.

We may delete anytime the building option and/or the associated components.

 

"Delete" a build option removes the Configuration property from the Associated components.

"Remove Components" from a Build Option actually deletes the APEX objects which have set the configuration to that build option. 

Important! Don’t Remove Components from an Include Build Option!

 How we can use the build options?

Scenario:

The team develops new features which will be released in 2 steps: in Release_1 and in Release_2. The team is well ahead with the development, having everything for Release_1 finished, and are halfway done with the development for Release_2.

Steps  

1. Create build options: We need to define as many build options as needed to cover the requirements: for our scenario, we need 2: Build_1 and Build_2

2. Set the configuration the components and features according to the release number they belong.

3. Set the proper status for the Build Option: for our Scenario, these will be:

    Release_1:  Build_1  Include; Build_2 Exclude

    Release_2:  Build_1  Include; Build_2 Include

Recommendation: to understand better how to correctly set the Build Options status and how to switch between Include and Exclude for different environments, create a simple demo application, follow a scenario that involves 3 different versions of the application in 2 environments and inspect the results. 

 Summary

Use Build Options every time you have in development at least 2 versions of the same APEX application. Don't use anymore the Server Side Condition " Never" to exclude components, use Comment Out Build Option instead.   

Read more about: Using Build Options to Control Configuration