3.4.1 Configuring Service-level Security Settings

Instance administrators can configure service-level security in Manage Instance, Security, Security Settings, Security.

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.

3.4.1.1 Controlling Workspace Cookies

Determine if Oracle APEX saves persistent cookies in the browser

Oracle APEX uses the following persistent cookies:

  • ORA_WWV_REMEMBER_UN - The development environment login page stores the Workspace and Username data in this cookie. It is used to populate these attributes with default values, when you log in again.
  • LOGIN_USERNAME_COOKIE - Customer application login pages use this cookie to store the Username. It is used to populate the attribute with a default value, when customers log in again.
  • ORA_WWV_REMEMBER_LANG - When using language selection in the development environment, APEX stores the language and territory in this cookie. It is used to automatically show the application in the selected language when the application is used next time.

If your system has received cookies, you can physically remove it from its persistent location on disk using browser tools or system utilities.

To configure if APEX saves persistent cookies:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. For Set Workspace Cookie, select one of the following:
    • Yes - Enables APEX to save persistent cookies in the browser.

    • No - Prevents persistent cookies from being sent.
  6. Click Apply Changes.

3.4.1.2 Controlling Persistent Authentication

Control if Persistent Authentication is enabled. Enabling Persistent Authentication enables developers to use a built-in API to let users choose to re-login to an application without having to provide credentials.

If Allow Persistent Authentication option is set to Yes, Oracle APEX sends a persistent cookie that:

  • Contains a hash value

  • Has a lifetime as configured in Persistent Authentication Lifetime Days

  • Is read to compare to the value that is stored in the database.

If your system has received cookies, you can physically remove it from its persistent location on disk using browser tools or system utilities.

To control Persistent Authentication:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. For Allow Persistent Authentication, select one of the following:
    • Yes - Enables the APEX Persistent Authentication API for the login page to send a persistent cookie.

      The additional configuration option Persistent Authentication Lifetime Days controls the lifetime of this cookie.

    • No - Disables persistent authentication on this instance.
  6. For Persistent Authentication Lifetime Days - Enter the maximum number of days users can login using Persistent Authentication before having to enter credentials again.
  7. Click Apply Changes.

Note:

If your system has received this cookie, you can physically remove it from its persistent location on disk using browser tools, system utilities. The cookie will have the same name as the session cookie, post-fixed with $P. It may exist for each application accessed having Persistent Authentication enabled.

See Also:

APEX_AUTHENTICATION in Oracle APEX API Reference

3.4.1.3 Disabling Access to Administration Services

Prevent a user from logging in to Oracle APEX Administration Services.

Instance administrators can prevent a user from logging in to Administration Services. Disabling administrator login in production environments prevents unauthorized users from accessing Administration Services and possibly compromising other user login credentials.

To disable user access to APEX Administration Services:

  1. Sign in to Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. For Disable Administrator Login, select Yes.

    Note:

    Selecting Yes and signing out prevents anyone from accessing Administration Services.

  6. Click Apply Changes.

3.4.1.4 Enabling Access to Oracle APEX Administration Services

If access to Oracle APEX Administration Services has been disabled, an Instance administrator can re-enable again by running the following SQL statements.

To enable user access to Administration Services if it has been disabled:

  1. Connect in SQL*Plus and connect to the database where Oracle APEX is installed as SYS, for example:
    • On Windows:

      SYSTEM_DRIVE:\ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
    • On UNIX and Linux:

      $ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
  2. Run the following statement:
    ALTER SESSION SET CURRENT_SCHEMA = APEX_220200;
    
  3. Run the following statement:
    BEGIN
      APEX_INSTANCE_ADMIN.SET_PARAMETER('DISABLE_ADMIN_LOGIN', 'N');
      commit;
    END;
    /
    

3.4.1.5 Disabling Workspace Login Access

Restrict user access to APEX by disabling workspace login. Disabling workspace login in production environments prevents users from running APEX applications such as App Builder.

To disable user access to the Internal workspace:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. From Disable Workspace Login, select Yes.

    Selecting Yes effectively sets a Runtime-Only environment while still allowing Instance administrators to sign in to Administration Services. Selecting Yes in production environments prevents developers from changing applications or data.

  6. Click Apply Changes.

3.4.1.6 Controlling Public File Upload

Use the Allow Public File Upload attribute to control whether unauthenticated users can upload files in applications that provide file upload controls.

To control file upload:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. From Allow Public File Upload, select one of the following:
    • Yes - Enables unauthenticated users to upload files in applications that provide file upload controls.

    • No - Prevents unauthenticated users from uploading files in applications that provide file upload controls.

  6. Click Apply Changes.

3.4.1.7 Restricting User Access by IP Address

Restrict user access to the APEX development environment and Administration Services by specifying a comma-delimited list of allowable IP addresses.

To restrict user access by IP address:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section and edit the following attributes:
    1. Disable Administrator Login - Select No.
    2. Restrict Access by IP Address - To restrict access to the Oracle APEX development environment and Administration Services to a specific range of IP addresses, enter a comma-delimited list of IP addresses.

      If necessary, use an asterisk (*) as a wildcard. However, do not include additional numeric values after wildcard characters. For example, 138.*.41.2 is not a valid value.

      You can enter IP addresses from one to four levels. For example:

      141, 141.* ...
      192.128.23.1 ...
      
  5. Click Apply Changes.

3.4.1.8 Configuring a Proxy Server for an Instance

Configure an entire APEX instance to use a proxy for all outbound HTTP traffic.

Note:

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

Setting a proxy at the instance-level supersedes any proxies defined at the application-level or in web service references. If a proxy is specified, regions of type URL, Web services, and report printing will use the proxy.

To configure a proxy for an APEX instance:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section and edit the following attributes:
    1. Instance Proxy - To require that all outbound HTTP(s) traffic from an Oracle APEX instance to use a specific proxy server, enter the proxy server address and port in this field.
      For example: www-proxy.example.com:80
    2. Instance No Proxy Domains - Provide a comma-separated list of domains for which the Instance Proxy should not be used.
  5. Click Apply Changes.

3.4.1.9 Selecting a Checksum Hash Function

Select a hash function that APEX uses to generate one way hash strings for checksums.

The Checksum Hash Function attribute enables you to react to recent developments and switch between algorithms based on new research. Use the Checksum Hash Function attribute to select a hash function that APEX uses to generate one way hash strings for checksums. This attribute is also the default value for the Security Bookmark Hash Function attribute in new applications. Applications use the Bookmark Hash Function when defining bookmark URLs.

Tip:

Changing the Checksum Hash Function does not change the Bookmark Hash Function currently defined for existing applications because this would invalidate all existing bookmarks saved by end users. Oracle strongly recommends going into existing applications, expiring existing bookmarks, and then updating the Bookmark Hash Function to the same value defined for Checksum Hash Function.

To select a checksum hash function:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. From Checksum Hash Function, select a hash function that APEX uses to generate one way hash strings for checksums.

    The SHA-2 algorithms are only supported on Oracle Database 12c or later. Most Secure automatically selects the most secure algorithm available. Therefore, Oracle recommends this setting. On Oracle Database 12c or later, this evaluates to SHA-2, 512 bit and on Oracle Database 11g, SHA-1 is the most secure algorithm. Since the MD5 algorithm is deprecated, Oracle does not recommend this setting.

  6. Click Apply Changes.

3.4.1.10 Configuring Rejoin Sessions for an Instance

Controls at the application-level whether URLs in this application contain session IDs.

By configuring the Rejoin Sessions attribute, Instance administrators can control if APEX supports URLs that contain session IDs. When Rejoin Sessions is enabled, APEX attempts to use the session cookie to join an existing session, when a URL does not contain a session ID.

To use Rejoin Sessions at the application or page-level, an administrator must enable Rejoin Sessions at the instance-level. A more restrictive instance-level setting overrides application and page settings.

Warning:

For security reasons, Oracles recommends that administrators disable support for session joining unless they implement workspace isolation by configuring the Allow Hostname attributes. See Isolating a Workspace to Prevent Browser Attacks and Isolating All Workspaces in an Instance.

Note:

Enabling rejoin sessions may expose your application to possible security breaches by enabling attackers to take over existing end user sessions. To learn more, see About Rejoin Sessions in Oracle APEX App Builder User’s Guide.

To configure Rejoin Sessions:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. From Rejoin Sessions, select an option:
    • Disabled - If the URL does not contain a session ID, APEX creates a new session.
    • Enabled for Public Sessions - If the URL goes to a public page and does not contain a session ID, APEX attempts to utilize the existing session cookie established for that application. For applications with both public and authenticated pages, a session ID is defined after the end user authenticates. APEX only joins via the cookie when the session is not yet authenticated.
    • Enabled for All Sessions - If the URL does not contain a session ID, APEX attempts to use the existing session cookie established for that application, providing one of the following conditions are met:
      • Session State Protection is enabled for the application and the URL includes a valid checksum. For public bookmarks, the most restrictive item level protection must be either Unrestricted or Checksum Required - Application Level.

      • The URL does not contain payload (a request parameter, clear cache or data value pairs). This setting requires that Embed In Frames is set to Allow from same origin or to Deny for the application.

      Enabled for All Sessions requires that Embed in Frames is set to Allow from same origin or Deny. This is not tied to a condition about the URL payload, but also applies to session state protected URLs.

  6. Click Apply Changes.

See Also:

3.4.1.11 Configuring Unhandled Errors

Control how Oracle APEX displays the results of unhandled errors

Note:

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

When Oracle APEX encounters an unhandled error during processing, an error page displays to the end user of the application. From a security standpoint, it is often better to not display these messages and error codes to the end user and simply return a HTTP 400 (Bad Request) error code to the client browser.

To configure Unhandled Errors:

  1. Sign in to APEX Administration Services.
  2. Click Manage Instance.
  3. Under Instance Settings, click Security.
  4. Locate the Security section.
  5. From Unhandled Errors, select an option:
    • Show Error Page - This is the default behavior. For any error or exception which is not handled by the error processing of an application, an error page displays to the end user with the specific error and the error code.

    • Return HTTP 400 - Returns an HTTP 400 status to the end user's client browser when the APEX engine encounters an unhandled error.

  6. Click Apply Changes.