Isolating All Workspaces in an Instance

Instance administrators can configure limits to isolate all workspaces and prevent browser attacks. Workspace administrators can override these default values at the workspace-level.

Note: To ensure the security and performance of your development environment, some administration functionality is not available in Oracle APEX instances running in Oracle Cloud.

About Isolating Workspaces to Prevent Browser Attacks

Isolating workspaces is an effective approach to preventing browser attacks.

The only way to truly isolate a workspace is to enforce different domains in the URL by configuring the Allow Hostnames attribute. When the URLs of the attacker and the victim have different domains and hostnames, the browser’s same-origin policy prevents attacks.

Workspace isolation by configuring Allow Hostnames is a counter measure against client-side attacks that attempt to cross workspace boundaries. This security measure is not necessary if you trust all applications that are accessible using the instance’s host which includes applications that are written in other frameworks and languages such as Oracle Application Development Framework (ADF) and Java.

Instance administrators can configure the Allow Hostnames attribute at the instance-level. Workspace administrators can override the instance-level setting for a specific workspace.

See Also: Isolating a Workspace to Prevent Browser Attacks

Configuring Instance-Level Workspace Isolation Attributes

Configure isolation and resource limitation default values for all workspaces in an instance.

Tip: Workspace administrators can override many default values at the workspace-level. See Isolating a Workspace to Prevent Browser Attacks.

To configure instance-level Workspace Isolation attributes:

  1. Sign in to APEX Administration Services.

  2. Click Manage Instance.

  3. Under Instance Settings, click Security.

  4. Under Workspace Isolation, configure the following attributes:

    Tip: To learn more about an attribute, see field-level Help.

    Attribute Description
    Allow Hostnames

    Enter a comma-separated list of hostnames that can be used to access this instance. This attribute can be used to specify which DNS aliases of the web server can be used with applications. You can configure specific values that override this one at workspace level. If you enter one or more hostnames, the incoming HTTP request URL's hostname part must match one of the listed hostnames.

    For example, you can register the DNS alias hr.example.com for your web server www.example.com. The instance value of Allowed Hostnames can be set to www.example.com. If you then set the HR workspace's Allow Hostnames to hr.example.com, users have to access HR applications using hr.example.com and all other applications of this instance using www.example.com. With this configuration, the browser's Same Origin security policy provides a client-side barrier between HR applications and other applications of the instance, which run in another browser tab or window.

    Resource Consumer Group

    Specify the Database Resource Manager consumer group to be used for all page events on the instance. The Resource Consumer Group provides more control of hardware resources such as CPU and I/O requests. Workspace-level settings override instance-level settings to enable administrators to provide more or less resources depending on the needs or importance of a workspace.

    At the beginning of every request, the APEX engine switches the current consumer group of the current database session to the consumer group that is defined at workspace or instance-level. This applies to both executing applications and any of the applications used within the APEX development environment.

    These limitations apply to all page requests where application code executes using the APEX engine which enables the assigned Resource Manager settings. However, these limitations do not apply to Oracle Scheduler jobs that workspace developers create, or to ORDS REST requests, where APEX is not in the code path.

    A call to set the workspace, such as apex_util.set_workspace('MY_WORKSPACE'); at the beginning of the scheduler job, enables the right consumer group. However, there is often no reason for developers to add this type call. Therefore, administrators should apply the Resource Manager consumer groups to both the APEX workspaces and to the workspace schemas (that is, the underlying database users).

    You must grant privilege to switch to a consumer group to either PUBLIC or the APEX schema. This privilege is typically granted using the procedure DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP.

    See Also: Managing Resources with Oracle Database Resource Manager in Oracle AI Database Administrator's Guide
    Maximum Concurrent Workspace Requests

    Enter the maximum number of concurrent page events that APEX supports for all applications. You can configure a specific value at the workspace-level. Instead of processing a page event, APEX shows an error message when the limit is already reached.

    APEX keeps track of workspace requests by querying the CLIENT_INFO column of GV$SESSION. This tracking will not work if developers overwrite CLIENT_INFO, for example, with a call to DBMS_APPLICATION_INFO.SET_CLIENT_INFO.

    Maximum Concurrent Session Requests

    Enter the maximum number of concurrent page events that APEX supports for each session for applications in this instance. You can configure a specific value at the workspace-level. Instead of processing a new page event, APEX shows an error message when the limit is already reached. Alternatively, you can use the Concurrent Session Requests Kill Timeout attribute to kill an active database session, to process the new page event.

    APEX keeps track of session requests by querying the CLIENT_IDENTIFIER column of GV$SESSION. This tracking will not work if developers overwrite CLIENT_IDENTIFIER, for example, with a call to DBMS_SESSION.SET_IDENTIFIER.

    Concurrent Session Requests Kill Timeout

    If a new page event comes in that is outside the limits of Maximum Concurrent Session Requests, APEX can execute alter system kill session on the oldest active database session which processes another page event for this APEX session. The Concurrent Session Requests Kill Timeout attribute specifies the number of seconds a database process has to be active, before it can be killed. If you leave this attribute empty, APEX will not kill any database sessions.

    Warning: Killing sessions can cause problems with the application server's database session pool.

    Maximum Size of Files in Workspace Enter the total size (in bytes) of all files that can be uploaded to a workspace. You can configure a specific value at the workspace-level.
    Maximum Web Service Requests Enter the maximum number of web service requests, within a rolling 24-hour period, that APEX supports for each workspace in this instance. You can configure a more specific value at the workspace-level.
    Maximum AI Tokens Enter the maximum number of AI Tokens per 24 hour period that APEX can use for Generative AI Services for each workspace in this instance. You can configure a more specific value at the workspace level or at the AI Service/Vector Provider level.

  5. Click Apply Changes.

See Also: