Oracle Application Express




There are three major considerations in respect of security:

Securing the Application Express Instance

Instance administrators are responsible for setting various instance wide options to ensure the appropriate level of security for both developing and deployed applications. You should also review the Oracle Application Express Application Builder User's Guide, Understanding Administrator Security Best Practices. To further harden your environments instance administrators should review the following settings either from Instance Administration or by running the appropriate APIs:

Feature Configuration
Enable SQL and PL/SQL Access In Websheets - Disable this option when you wish to prevent Websheet users from accessing underlying database objects using the SQL tag, creating SQL reports or creating PL/SQL sections.
Enable RESTful Services - Disable this option if you do not want to allow developers to create and edit RESTFul Web Services mapped to SQL and PL/SQL in conjunction with the APEX Listener Release 2.0 and above.

Disable Workspace Login - Set to Yes in test and production environments when "Runtime Only" not installed.
Allow Public File Upload - Set to No to prevent public (unauthenticated) users from uploading files.
Restrict Access by IP Address - Enter a comma-delimited list of allowable IP address ranges.
Instance Proxy - Specify the proxy server address to be used for all outbound traffic.
Require HTTPS / Outbound HTTPS - Providing HTTPS is enabled on your server, switch both to Yes to force all authenticated pages within the Application Builder to require HTTPS which encrypts network communications.
Allow RESTful Access - Disable this option if you don't want developers exposing report regions as RESTful services.
Session Timeout - Control the maximum session length and idle time as appropriate such that users must re-authenticate after a certain period. These settings can be overwritten by application-level settings.
General Login Control - Set delays after failed login attempts to prevent login bots, and specify an inbound proxy server.
Workspace Password Policy - Set various parameters to adjust how strong the passwords for all workspace users, including Application Express end users, needs to be.

Instance Settings
Self Service / Email Provisioning - Specify the amount of automation when developers request new workspaces.
Storage - Define if workspaces can utilize existing schemas, and specify tablespaces for new schemas to be encrypted.
Email - Define the email SMTP settings and set the "Use SSL/TLS" to use a secure connection for Oracle Database 11gR2 and above.
Wallet - Define the wallet, a password-protected container used to store authentication and signing credentials, used for all HTTPS requests.

Workspace Purge Settings
For large installations where there are regular requests for new service and/or limited database resources, instance administrators can define purge settings which will automatically send emails to workspace administrators whenever their workspace has been inactive for a specified period. If one of the workspace administrators does not respond to the emails saying they want the workspace preserved then it will be purged. Purging a workspace will remove old applications and release the space they utilized.

Manage Workspaces
Manage Workspace to Schema Assignment - Define the many-to-many associations between workspaces and schemas as appropriate.
Manage Developers and Users - Use this to define what schemas a specific user has access to and also whether they are a workspace administrator, developer or an end user. You can also limit developer access to specific Application Builder components and lock a specific account.
Manage Component Availability - Change access to Application Builder, SQL Workshop, and PL/SQL editing which will limit developer access across a workspace. For example, if you wanted users to be able to build database components, run SQL statements, etc but not build applications, you could define a workspace with rights to a specific schema and then configure the users as developers using this feature.

Workspace Security Settings

Workspace administrators are responsible for setting various workspace options to ensure the appropriate level of security within their workspace. From Administration > Manage Service > Set Workspace Preferences administrators can set the Account Login Control. This is specifically for Application Express end users and enables you to set the maximum login failures and the account lifetime. You can also disable access to Application Builder components or disable RESTful Services as needed.

Securing Applications

Application developers are responsible for developing secure applications. You should review the Oracle Application Express Application Builder User's Guide, Managing Application Security. Within Application Properties you can define the proxy server for the application, which will overwrite the instance value if set. You can also override instance settings for maximum session length and idle time and specify the URLs to redirect to.

Defining the appropriate authentication scheme (that is, establishing a user's identity) for an application is critical to ensure only appropriate users can log into the application. As a developer, you must determine which pages do not require authentication (also known as public pages). These pages should never contain any sensitive information. You should also define authorization schemes to easily define access to different application components. It is very important to use the appropriate authorization on sensitive pages and the navigation controls (tabs, buttons, links, etc.) used to access the page(s). You can also use authorizations on processes, validations and computations to ensure only authorized users can maintain specific data.

One of the key security measures you can adopt is Session State Protection (SSP) to limit URL tampering. Such protection can be defined for pages, page items and application items. To prevent URL tampering, all possible components should be configured with SSP. The only exceptions should be public pages and page items which are used with JavaScript such as an item used as a parent in a cascading list of values. Please note that once session state protection is set using the built-in wizards that any new pages or items defined will need to have their protection set manually.

As a developers it is important for you to also understand hardening items, especially password items. Password items should not be saved or encrypted in session state and have restricted session state protection. Where available, you should ensure that Form items have the HTML escaped. It is also advisable to restrict the enterable characters for text items to limit cross site-scripting and other injection attacks. Report regions and dynamic output should also be escaped to prevent attacks.

As a best practice, once you have completed development of your application run the Application Advisor (under Utilities). This includes many checks for conditions which could present security vulnerabilities. There are also third party tools available which extensively analyze applications for vulnerabilities. The two tools currently available are APEXSec Security Tool and APEX-SERT.