Trusted Digital Transformation Partner
OWASP Top 10 for Enterprise ERP Applications: A Secure-by-Design Guide for Oracle APEX & Custom Development (2026)
- By ROSTAN Technologies Consulting Team
- Published Sep 09, 2026
Enterprise ERP and low-code applications (Oracle APEX, custom Laravel portals, internal tools) face a different threat model than public consumer web apps — the biggest real-world risk is Broken Access Control between roles that already have valid logins, not an anonymous attacker from the internet. OWASP Top 10 guidance still applies, but it needs re-reading through that lens: role separation, not just authentication, is where most ERP-adjacent applications actually fail.
Most OWASP Top 10 guidance is written with a public-facing consumer web application in mind — the attacker is an anonymous stranger, and the goal is keeping them out. Enterprise ERP applications, Oracle APEX portals, and internal Laravel/Node tools have a different, arguably harder problem: most of the people who could cause damage already have a valid login. The threat model is a finance clerk who should only see their own department's data seeing another department's, or a vendor-portal user finding a URL parameter that lets them view another vendor's invoices. That is Broken Access Control, and it is the single most common serious finding in enterprise application assessments.
Why ERP-Adjacent Applications Are a Different Threat Model
- Every user is already authenticated — the attacker in most real incidents is not bypassing a login; they are a legitimate user acting outside the boundary of what their role should permit.
- Role structures are complex and change over time — an ERP with dozens of roles, delegated approvals, and department-based data segregation accumulates access-control edge cases faster than a simple consumer app with two or three user types.
- Low-code platforms make it easy to expose more than intended — Oracle APEX, in particular, makes it fast to build a page against a database view; it is equally fast to forget a session-state check that should have scoped that view to the current user's department.
- Integration surface is larger — ERP systems talk to payment gateways, e-invoicing APIs, and other internal systems, each an additional point where an access-control or injection flaw can have financial, not just data-exposure, consequences.
OWASP Top 10, Mapped to Enterprise ERP Applications
| OWASP Category | What it looks like in an ERP/APEX context |
|---|---|
| Broken Access Control | A URL/record ID parameter that lets one user view or edit another user's or department's records by changing an ID, without a server-side ownership check |
| Cryptographic Failures | Sensitive fields (bank account numbers, salary data) stored or logged in plaintext where the database or application logs are broader-access than the field itself should be |
| Injection | Dynamic SQL built from user input in a custom PL/SQL procedure or report parameter, rather than bind variables |
| Insecure Design | An approval workflow with no server-side enforcement of sequence — a request approvable by skipping a step through direct URL access |
| Security Misconfiguration | A default APEX workspace or admin account left with a default/weak password after go-live |
| Vulnerable and Outdated Components | A Laravel application running dependencies with known CVEs because nothing in the CI/CD pipeline flags them |
| Identification and Authentication Failures | Shared service accounts used by multiple people, making an audit trail useless for establishing who actually did what |
Broken Access Control: the Deep Dive
This deserves the most attention because it is, in practice, the finding that actually causes damage in ERP-adjacent applications. The pattern is almost always the same: a page or API endpoint checks that the user is logged in, but not that the specific record being requested belongs to that user, their department, or their approval chain. In Oracle APEX specifically, this often means a report or form built against a view that returns all rows, with the "scope to current user" filter applied only in the visible UI — not enforced in the underlying SQL, so a modified request or a direct API call bypasses it entirely. The fix is boring and non-negotiable: every data access must be scoped server-side to what the authenticated user's role actually permits, checked on every request, not assumed from the UI the user is expected to click through.
Secure-by-Design in the CI/CD Pipeline
Catching these issues in a pre-launch review is better than not catching them at all, but catching them automatically before every deploy is better still:
- Static Application Security Testing (SAST) scanning on every build, tuned to flag dynamic SQL construction and missing authorization checks specifically, not just generic patterns
- Dependency / Software Composition Analysis (SCA) scanning so a library with a known CVE fails the pipeline rather than reaching production silently
- Secrets scanning to catch a database credential or API key accidentally committed to source control before it ships
- A documented access-control test as part of QA — logging in as a lower-privilege role and attempting to access a higher-privilege record by manipulating the URL/ID, on every release that touches data access
A Practical Secure Development Checklist
- Every query and API endpoint scopes results server-side to the authenticated user's actual role and department — never rely on the UI alone to hide what a request could otherwise return
- Bind variables for every dynamic query; no string-concatenated SQL, in APEX PL/SQL or anywhere else
- Individual accounts for every user and system integration — no shared service accounts where an audit trail needs to mean something
- Dependency and secrets scanning wired into CI/CD, not run manually before a release if someone remembers
- An access-control-specific test pass before every release that touches authorization logic, not just a general QA pass
ROSTAN's Security Practice
ROSTAN Technologies builds Secure-by-Design Development into the Oracle APEX, Laravel, and custom applications we deliver, and offers standalone Application Security Assessments (VAPT) for applications built by another team — with particular depth in the access-control testing that generic web-app security tooling frequently misses in ERP-adjacent systems.
Explore our Cybersecurity Services or request a free security review.
Frequently Asked Questions
Have questions about Oracle, AWS or Cloud?
Talk to our certified experts — free consultation, no commitment.
