Oracle APEX – The Standard Component Attributes Anatomy Series: Security

In this third post of The Standard Component Attributes Anatomy Series, I’m tackling the Security attribute. Since the Security section includes references to Authorization Schemes from Shared Components, we’ll briefly touch on that as well.

And because there are specific security-related attributes at both the page and item levels, I’ll be covering those here too for a more complete picture.

Security

In the Security section of a component's attributes, you may encounter different security-related options depending on the type of component you're working with. However, one attribute is common to all component types: the Authorization Scheme.

This attribute allows you to control access to a component by selecting a predefined authorization scheme—or its negation— meaning the component will be rendered or executed only if the user does meet the criteria defined in the scheme.

Unlike the Read-only attribute, which can be overridden by a child component, the Authorization Scheme and Server-Side Condition attributes are enforced at the parent level and cannot be bypassed or redefined by child components.

Authorization Scheme

Before assigning an authorization scheme to a component, you must first define it under Authorization Schemes in the Security section of Shared Components. Each scheme includes a logic block (typically PL/SQL or SQL) used to determine whether the current user meets the specified condition.

A key aspect to understand here is the Evaluation Point, which determines when and how often an authorization scheme is evaluated during a user session. As per Oracle's documentation:

• Once per session: The scheme is evaluated only once per session, and the result is cached for all future uses.

• Once per page view: Evaluated once per request. If the same scheme is used in multiple components on the same page, the result is reused.

• Once per component: Evaluated individually for each component using the scheme, but results are cached in the session for reuse across requests.

• Always (No Caching): The scheme is evaluated every time it is referenced—no caching occurs.

Choosing the right evaluation point can have an impact on both performance and security, so it’s important to consider how dynamic your access rules are and how often they might change within a session.

You might be wondering—and rightly so—how authorization schemes differ from server-side conditions, since both are used to control component visibility or execution. While they may seem similar at first glance, authorization schemes serve a slightly different purpose and operate at a higher level.

Authorization schemes are typically centralized, reusable conditions that can be assigned to multiple components across your application. They support caching, which improves performance by avoiding repeated evaluations. This makes them ideal for access control scenarios, such as role-based restrictions, where the logic doesn't change frequently within a session.

On the other hand, server-side conditions are always evaluated at runtime, every time a component is processed. This behavior is functionally equivalent to setting an authorization scheme to "Always (No Caching)", which disables caching altogether.

If you're interested in server-side conditions, check out the previous blog post dedicated to that topic.

Keeping the number of authorization schemes at a reasonable level is key to maintaining long-term control and clarity in your Oracle APEX application. If you create too many narrowly scoped schemes—essentially micromanaging access—you risk creating a tangled web that’s hard to maintain. On the other hand, using only a few overly broad schemes might not give you the granularity needed for complex applications.

A good compromise is to design modular, reusable authorization schemes—but also build in a way to reset their cached results when necessary.

Let me explain with an example.

Imagine you’re building a project management application, where users can take on different roles in different projects (e.g., Manager in Project A, Viewer in Project B). To support this, you might have a select list that allows users to switch between projects, storing the selected project ID in an application item like AI_PROJECT_ID.

Now, suppose you have an authorization scheme that determines what a user is allowed to do based on their role in the selected project.

sample_security_package.auth_is_user_pm(
    p_username    => :APP_USER, 
    p_role_code   => 'PM', 
    p_project_id  => :AI_PROJECT_ID);

Since authorization schemes can cache results (depending on their evaluation point), you might run into a situation where the cached result doesn't reflect the newly selected project—because the scheme was already evaluated earlier in the session.

To solve this, you can manually reset the authorization cache when the user switches projects. This ensures that the next time the scheme is evaluated, it runs fresh with the correct context.

You can achieve this by calling the following built-in procedure:

APEX_AUTHORIZATION.RESET_CACHE;

Page specific attributes

Oracle APEX allows certain security settings, usually defined at the application level, to be overridden at the page level. This gives developers fine-grained control over how individual pages behave in terms of access, caching, and session protection.

Authentication

Determines whether a page requires authentication or is publicly accessible. One of the first things APEX does when generating a page is check whether the user is allowed to access it. This is handled by the Page Sentry function, which validates key security aspects such as the username, session validity, and more.

If the check passes, page generation continues; otherwise, the user is redirected to the URL defined in the "Go To" attribute of the authentication scheme in use.

While it's possible to define a custom Page Sentry function, it’s generally not recommended unless you have a very specific security need.

Deep Linking

Conceptually, deep linking allows users to "land" directly on a specific page within an application's flow, often with pre-set page items passed via URL parameters.

For example, in an email marketing campaign, your call-to-action might link to a specific APEX page. Each recipient could receive a dynamically generated URL that sets user preferences via parameters—ensuring the page displays personalized content that matches the email context.

In enterprise applications (where APEX is often used), you might want users to go directly to an Approval Request page, loading for instance REQUEST_ID=1234 via the URL so they can immediately approve or reject it.

If this attribute is disabled, APEX will ignore and strip out any parameters passed in the page URL.

If enabled, and a valid APEX session exists, the page will load directly with all URL parameters preserved.
If the user isn’t authenticated, they’ll be redirected to the login screen first. After successful login, APEX will take them to the originally requested page, with all parameters intact.

This setting only applies to external requests. Internal navigation within the application is not affected by the Deep Linking setting.

By default, Deep Linking is disabled at the application level under the Security section in Shared Components. However, to simplify development, Deep Linking is always enabled when the user is logged into the APEX development environment.

It’s also important to note that if the target page’s security settings require a checksum for arguments, a valid checksum must be included along with the parameter values.

In scenarios like the email example, you’ll need to use the older API function APEX_UTIL.PREPARE_URL to generate the link URL, which allows you to explicitly define the type of checksum required. The newer APEX_PAGE.GET_URL function does not offer this level of control, making it unsuitable when protected items are involved.

Page Access Protection

Page access protection determines whether a request can render the page, whether it can set the values of page or application items, and under what conditions, such as requiring a checksum. The available options are:

• Unrestricted: The page can be accessed via URL with or without session state arguments.

• Arguments Must Have Checksum: URL arguments require a checksum to ensure security.

• No Arguments Supported: The page can be accessed via URL but without any parameters.

• No URL Access: The page can only be accessed internally (e.g., via branches), not by direct URL.

Let’s focus for a moment on the second option, “Argument must have a checksum.” This default option instructs APEX to recalculate and validate the argument values against the provided checksum to ensure that users cannot manipulate the values. This attribute is related to the item security setting, “Session State Protection,” which dictates the type of checksum required for that specific item.

When generating a link to a specific page, APEX checks the target page and its item configuration to generate the correct checksum value. For example:

p3_empno=7566
clear=3
session=11155673235579
cs=1aGnPAKiqEoe1HtNuF.......OhLVhVG2cVLQwl4B84d

If you look closely at the arguments passed in the URL, you’ll notice that in this simple example, the page item P3_EMPNO is set to 7566 and the Clear Cache is set to 3. Behind the scenes, APEX adds a third argument, likely called cv (Checksum Value), which is a hash generated from the page and item values. When the page executes, APEX recalculates this hash to verify that the passed values haven’t been tampered with.

Form Auto-Complete

Enables or disables browser auto-complete on form fields. Setting this to Off adds autocomplete="off" to the HTML form tag. Behavior may vary across browsers.

As per MDN, the HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field.

Browser Cache
Controls whether the browser can cache page content:

• Enabled: Allows caching in memory or on disk.

• Disabled: Sends the cache-control: no-store header to prevent caching—recommended for security.

• Application Default: Inherits the setting from the application-level security attributes.

Oracle recommends disabling browser cache for pages displaying sensitive data, to avoid the risk of viewing stale content after logout via the browser's back button.

Items specific attributes

In the case of items, apart from the already mentioned generic Authorization scheme, we can set three additional attributes, two related to session state and one related to data sanitazion:

Session State Protection

Oracle APEX provides granular control over how page items handle session state and URL-based data submission through the Session State Protection attribute. This setting determines the security level for each item, helping prevent unauthorized data manipulation via URLs or forms.

• Unrestricted

• Checksum Required – Application Level

• Checksum Required – User Level

• Checksum Required – Session Level

• Restricted – May not be set from browser

The first and last options are straightforward. Normally, items where the user is expected to enter data are set to Unrestricted. This must also be the case for hidden or display-only items that are dynamically populated after page rendering. For example, you might use the additional output of a Popup LOV to fill display-only fields. If a user selects a 'restaurant' record from a list, the corresponding full address could be automatically populated so it can be submitted and processed later.

Restricted, on the other hand, is suitable for items that are computed or fetched during page rendering and are not intended to be modified by the user. In my experience, this setting is rarely applied at the page level but is commonly used for application items that are precomputed at the start of a session and control application behavior.

The other three options relate to checksums. They instruct APEX to validate that the argument passed corresponds to the checksum value, ensuring data integrity when fetching and rendering the page. These options allow you to control the security level of the checksum:

• Session Level (default, most secure): The checksum applies only to the current session. This is ideal for forms triggered from a record in a report within a valid user session.

• User Level: The checksum is valid as long as the application user is the same. This is useful when a user wants to save a bookmark to a specific page with arguments to access later.

• Application Level (least secure): The checksum is valid for any user of the application. This is typically used for email links, where multiple users might access the page with the same arguments. In this case, it’s advisable to add an extra security check to ensure that the user has the proper rights to view the record.

Store value encrypted in session state

This attribute is straightforward—it lets you encrypt the item’s value when stored in session state. If the item contains sensitive data, enabling encryption ensures that the value is protected in APEX’s session state management tables.

Without encryption, anyone with access to the APEX metadata tables could potentially query and retrieve this sensitive information.

As mentioned, APEX is secure by default, so this feature is enabled automatically.

Restricted characters

This attribute allows you to declaratively sanitize values submitted by the user. As a developer, you may recall the first security rule: “never trust the user.” Out of the box, APEX supports a limited set of parameters for the escape function, which include:

• All characters can be saved

• Allowlist for a–z, 0–9, and space

• Blocklist HTML command characters (< > ")

• Blocklist & < > " / ; , * | = % and --

• Blocklist & < > " / ; , * | = % or -- and new line

For example, if you configure it to allow only letters and numbers, APEX will raise an error whenever the submitted value contains any other characters.

If these options don’t meet your needs, APEX—as always—gives you full control over your settings. In this case, the APEX_ESCAPE package allows you to sanitize and escape user inputs with greater granularity. You can find the full documentation here.

Enjoy life!