Broken access control
authorization flaw / insecure direct object reference / privilege escalation / OWASP A01
Broken access control is an application letting someone see or do something their account should not. OWASP ranks it first in its 2025 Top 10 and reports that 100 percent of applications tested had some form of it. The rule that matters: a check enforced only in the browser is not a check.
OWASP states the job in one line: access control enforces policy such that users cannot act outside of their intended permissions. When it fails, the result is unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user's limits. It sits at number one in the 2025 Top 10, and the finding behind that placement is blunt. Maintaining its position at the top, 100 percent of the applications tested were found to have some form of broken access control.
NIST frames the same idea by granularity. Access control is the process of permitting or restricting access to applications at a granular level, such as per-user, per-group, and per-resources, and it restricts resource access to only authorized entities. So the question is never whether your application has logins. It is which records each individual account can reach once it is inside.
The failure worth picturing is OWASP's third example. An application puts all of their access control in their front-end, so the browser hides the admin page from anyone who should not have it, and an attacker runs one command line request against the same address and gets the page anyway. OWASP's rule follows from that: access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata. The other example is even plainer, and it is the one that ends up in the news: permitting viewing or editing someone else's account by providing its unique identifier.
The prevention list is short and mostly about defaults. Except for public resources, deny by default. Implement access control mechanisms once and reuse them throughout the application, rather than writing the check again on every screen. Model access controls should enforce record ownership rather than allowing users to create, read, update, or delete any record. And log access control failures, alert admins when appropriate, so a probe looks like something rather than nothing.
In practice
This is the flaw that reaches you as a phone call from a customer who saw another customer's information. It is cheap to get right while the data model is being designed and expensive afterwards, because retrofitting ownership rules means revisiting every screen that ever read a record. That timing is the reason it belongs in the conversation before the build starts rather than in a security review at the end.
Not the same as
- Authentication
- Authentication establishes who is asking. Access control decides what that account may then reach. An application can log everyone in correctly and still hand any of them any record.
- Hiding the menu
- A control that only removes a link, a button or a screen from the display is a display choice. OWASP's own scenario has the hidden page fetched anyway from the command line.
Why it matters to you
Custom software is quoted on features, and permissions are not a feature anyone demonstrates. That is exactly why this is the flaw OWASP finds most often. Asking two or three specific questions early costs you nothing and moves the work from something nobody scoped to something somebody owns.
What to ask or check
- 01Is every permission check enforced on the server, or does any screen rely on the browser to hide what it should not show?
- 02Is there one access control mechanism reused across the application, or a separate check written screen by screen?
- 03If a record identifier appears in a web address, what stops someone changing it to a number that belongs to another customer?
What people get wrong
That having logins means having access control. Authentication establishes who is asking; access control decides what that account may reach. OWASP's examples are mostly of logged-in users reaching records that were never theirs.
Red flags
- Permissions described only as which menus each type of user sees.
- No log of denied access attempts, so a probe looks like nothing.
- Record identifiers in the web address with no answer about what stops someone changing them.
Who owns it
The team building the application, at the point the data model is designed. It is not something a security review bolts on afterwards.
Where you will see it
In the address bar, most of the time. A record number sitting in a web address is where OWASP's first example scenario starts.