Previous Next JavaScript must be enabled to correctly display this content

## 3.11.3 Isolating a Workspace to Prevent Browser Attacks

Workspace administrators can prevent browser attacks by isolating a specific workspace. Workspace-level settings override those configured for an entire instance.

Note:

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

- About Isolating a Workspace to Prevent Browser Attacks
  Isolating workspaces is an effective approach to preventing browser attacks.
- Configuring Workspace Isolation Attributes
  Configure Workspace Isolation attributes.

Parent topic: Managing Existing Workspaces

### 3.11.3.1 About Isolating a Workspace 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 cofigure the Allow Hostnames attribute at the instance-level. Workspace administrators can override the instance-level setting for a specific workspace.

See Also:

Isolating All Workspaces in an Instance

Parent topic: Isolating a Workspace to Prevent Browser Attacks

### 3.11.3.2 Configuring Workspace Isolation Attributes

Configure Workspace Isolation attributes.

To configure Workspace Isolation attributes:

1. View the existing workspace:
   1. Sign in to Oracle APEX Administration Services.
   2. Click Manage Workspaces.
   3. Under Workspace Reports, click Existing Workspaces.
   4. Click a workspace name.
2. On the Edit Information page, locate Workspace Isolation and edit the attributes as described in the following table.

   Tip:

   To learn more about an attribute and view examples, see field-level Help.

   Attribute | Description
   --- | ---
   Allow Hostnames | Enter a comma separated list of hostnames that can be used to access this workspace. If you leave this attribute empty, the instance-level value applies. 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`. If you 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. If your workspace uses RESTful services, you have to additionally configure a pool in the `url-mapping.xml` configuration file of Oracle REST Data Services for isolation. Note that Oracle REST Data Services will ignore the RESTful Path Prefix workspace attribute if Allow Hostnames is configured. The configuration example below specifies that RESTful services of the HR workspace can only be accessed using `https://hr.example.com/apex/resource-handler`: `<pool base-url="https://hr.example.com/apex" name="apex" workspace-id="hr" />`
   Resource Consumer Group | Specify the Database Resource Manager consumer group to be used for all page events associated with this workspace. If you leave this attribute empty, the instance level value applies. 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, they 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 both to 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 of this workspace. If you leave this attribute empty, the instance-level value applies. Instead of processing a page event, APEX shows an error message when the limit is already reached. APEX keeps track of session 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 workspace. Instead of processing a new page event, APEX shows an error message when the limit is already reached. Alternatively, 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. This attribute specifies the number of seconds a database process has to be active, before it can be killed. If you leave this attribute empty, the instance-level value applies. 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 this workspace.
   Maximum Email Messages | Enter the maximum number of email messages that can be sent with the `APEX_MAIL API` per 24 hour period. This value overrides the instance-level setting.
   Maximum Web Service Requests | Enter the maximum number of email messages that can be sent with the `APEX_MAIL API` per 24 hour period. This value will override the instance-level setting.
   Content Cache target size | Denotes the target size for the content cache on workspace-level. The content cache can currently being used by Web Source and REST Enabled SQL services. The Cache Size Target acts as a soft limit, which, for performance reasons, is only maintained by the APEX scheduler jobs. In other words, APEX might exceed the specified limit during normal operations. With the next run of the maintenance job, cached content with the shortest remaining validity will be removed until the cache size is below the specified limit.
   Content Cache maximum entry size | Denotes the maximum size for content to be placed into the content cache. This value will override the instance-level setting. This value overrides the instance-level setting.
   Maximum Background Page Process Jobs | Specifies the maximum amount of scheduler jobs being available for background execution of page processes for this workspace (applies to all applications). Only the configured amount of jobs will run at the same time to execute page processes in the background. If the configured maximum amount of scheduler jobs is active, new submitted executions will wait until a job becomes available. See Also: "Configuring Limits for Concurrently Running Scheduler Jobs" section in About Background Page Processes in Oracle APEX App Builder User’s Guide

3. Click Apply Changes.

Parent topic: Isolating a Workspace to Prevent Browser Attacks