Securing APEX: Hiding the URL Format

Hiding URL format in APEX is essential for enhancing security and preventing the exposure of sensitive information. Oracle Application Express (APEX) uses a default URL structure that can reveal critical details, making it a potential target for attacks. In this article, we explore effective strategies to conceal the URL format in APEX and strengthen application security.

Risks of an Exposed URL in APEX

APEX URLs typically follow a format like the following:

This structure can expose:

• Application ID (100 in the example).

• Page number (1).

• User session (12345678901234), which can be targeted by attacks like session fixation.

• Additional parameters that could be manipulated by attackers.

Strategies to Hide the URL Format

1. Using Application and Page Aliases & Enabling “Friendly URLs” in APEX

Instead of displaying the application ID and page number, custom aliases can be defined.

Example:

• Application Alias: secure_app

• Page Alias: home

Resulting URL:

This makes the URL more user-friendly and conceals internal details.

APEX allows configuring friendly URLs through application and page aliases. To enable this:

1. Go to Shared Components > Application Definition.

2. Configure Application Alias.

3. Assign aliases to pages under Page Attributes.

2. Using Reverse Proxy and URL Rewriting to Hide APEX

A reverse proxy like Nginx or Apache can help completely mask the actual URL structure, ensuring that users never directly see any reference to APEX. This not only enhances security but also provides a smoother user experience.

The web server can implement rewriting rules to transform exposed URLs into cleaner and more secure routes. Additionally, it can apply extra rules to redirect accesses to customized paths, segment application resources, and further conceal the underlying technology. This includes directing different types of traffic to specific routes instead of exposing APEX endpoints directly.

Example in Apache:

Parameter Explanation

Apache Parameters

• RedirectMatch permanent "^/$" "/app/home"; → Redirects the root site to a specific page.

• ProxyRequests off; → Disables Apache from acting as an open proxy.

• RewriteEngine On; → Enables URL rewriting.

  • RewriteRule ^/ords/pdb/r/schema/app/(.*)$ /app/$1 [R=307,L,QSA]; → Redirects requests to a cleaner URL. It is necessary because, sometimes, Oracle Apex will send the complete URL.

  • R=307: This indicates an HTTP 307 Temporary Redirect. Unlike a 301 (Permanent Redirect), a 307 ensures that the request method (GET, POST, etc.) is preserved. This is useful for maintaining session integrity and preventing unintended method changes in client requests.

  • L (Last Rule): This stops processing any further rewrite rules if the current rule matches. It prevents unnecessary processing and ensures that only the intended redirection occurs.

  • QSA (Query String Append): This ensures that any query parameters present in the original URL are appended to the rewritten URL. Without this flag, query strings would be discarded, potentially breaking functionality.

• ProxyPass "/app/" "http://internal.myapp.com/ords/f?p=100:1"; → Redirects /app/ to an internal backend.

• ProxyPassReverse "/app/" "http://internal.myapp.com/ords/f?p=100:1"; → Ensures backend response consistency.

• ProxyPass "/static/" "http://internal.myapp.com/i/"; → Redirects static files to an internal path, this is only useful if you don’t use the CDN.

• ProxyPassReverse "/static/" "http://internal.myapp.com/i/"; → Adjusts responses for static file, this is only useful if you don’t use the CDNs.

• ProxyPass "/media/" "http://internal.myapp.com/ords/pdb/r/schema/"; → Redirects resources allocated in the schema path.

• ProxyPassReverse "/media/" "http://internal.myapp.com/ords/pdb/r/schema/"; → Adjusts schema files responses.

• ProxyPass "/js/" "http://internal.myapp.com/ords/pdb/r/"; → Hides /r/ routes.

• ProxyPassReverse "/js/" "http://internal.myapp.com/ords/pdb/r/"; → Maintains /r/ response consistency.

• ProxyPass "/general/" "http://internal.myapp.com/ords/pdb/"; → Redirects pdb resources to a cleaner path.

• ProxyPassReverse "/general/" "http://internal.myapp.com/ords/pdb/"; → Adjusts responses for consistency.

• Header unset X-Powered-By; → Hides information about the Apache server.

• Header unset Server; → Prevents exposing server version details.

• SSLCertificateFile /etc/letsencrypt/live/myapp.com/fullchain.pem; → Specifies the SSL certificate file.

• SSLCertificateKeyFile /etc/letsencrypt/live/myapp.com/privkey.pem; → Specifies the SSL private key.

• Include /etc/letsencrypt/options-ssl-apache.conf; → Applies recommended SSL security configurations.

Note: media, general and js are only examples.

Hiding the URL format in APEX is a key strategy to enhance application security. By using aliases, server rules, reverse proxies, and native APEX configurations, it is possible to reduce the exposure of sensitive information and minimize attack risks. Additionally, hiding APEX static files prevents attackers from easily identifying the technology in use. Implementing these measures not only protects the application but also improves the user experience with cleaner and more memorable URLs.