Top 10 Security Mistakes in Oracle APEX (and How to Fix Them)
Oracle APEX is a powerful low-code platform — but with great power comes the need for strong security. Over the years, I’ve seen many APEX apps fall into the same traps. Here are the top 10 most common security mistakes, and how to fix them immediately.
1. Not Enforcing Session State Protection (SSP)
The mistake: Developers leave items unprotected, allowing URL tampering.
Fix:
Use:
- Session State Protection = Checksum Required – Session Level
- Enable URL Tamper Protection for sensitive items
2. Hardcoding Sensitive Credentials in PL/SQL
The mistake: API keys, passwords, tokens stored directly in code.
Fix:
Store secrets in:
- APEX Credentials
- Oracle Wallet
- Encrypted columns with DBMS_CRYPTO
3️. Leaving Pages & Components Unauthenticated
The mistake: Public access set accidentally on pages or REST services.
Fix:
- Set page Authentication = Required
- Review Authorization Schemes for all processes
- Use “Must Not Be Public” security checks
4️. Weak Authorization Logic
The mistake: Developers check roles on the front-end only.
Fix:
- Enforce authorization both at page and component-level
- Use database roles or APEX roles via Authorization Schemes
5️. Using Dynamic SQL Without Binding Variables
The mistake:
EXECUTE IMMEDIATE 'select * from users where id=' || p_id;
Fix:
Always use:
EXECUTE IMMEDIATE
'select * from users where id=:1' USING p_id;
This eliminates SQL injection risks.
6️. Storing Sensitive Data in Session State
The mistake: Saving passwords, personal data, or tokens in page items.
Fix:
- Set “Store Value = No” for sensitive items
- Use Collection / PL/SQL variables instead of session state
- Avoid APEX_UTIL.SET_SESSION_STATE for secret data
7️. Missing Bind Variables in Interactive Reports
The mistake: IR/IG filters exposing internal column names or allowing injection.
Fix:
- Use Bind Variables in report SQL
- Restrict exposed columns
- Sanitize user filters
8️. Not Enabling Browser Security Headers
The mistake: Apps run without protection against script injection or clickjacking.
Fix:
Enable in APEX:
- Content Security Policy (CSP)
- X-Frame-Options
- X-Content-Type-Options
- Strict-Transport-Security
9️. Not Using HTTPS Everywhere
The mistake: Apps accessible via http, exposing cookies & credentials
Fix:
- Force HTTPS in the web server (Apache/Tomcat/ORDS)
- Enable Secure Cookie Flags
- Disable all http endpoints
10. Overprivileged Database Accounts
The mistake: APEX schemas with GRANT ALL or unnecessary write privileges
Fix:
Follow least privilege principle:
- Separate schema for APEX parsing schema.
- No DDL rights for runtime users.
- Use invoker's rights packages where needed.
Final Thoughts
Oracle APEX is secure by design — but only if developers configure it correctly. A few careful steps can protect your application from SQL injection, session hijacking, URL tampering, and unauthorized data access