Broken Access Control
Key Takeaways
- Broken access control means a user can reach data or actions that should be off-limits to them, and it sits at number one on the OWASP Top 10.
- Access control is the enforcement layer, while authorization is the policy that says who should have access. Confusing the two leads to gaps.
- IDOR is one of the most common forms of broken access control, exposing records simply by changing an ID in a request.
- These flaws are logic problems, not misconfigurations, so automated scanners miss most of them.
- Preventing them takes deny-by-default design plus testing that reasons about who each user actually is.
What Is Broken Access Control?
Broken access control is a flaw that lets a user perform actions or reach data outside their intended permissions. A standard account viewing another customer’s invoice, a regular user hitting an admin-only endpoint, an unauthenticated request that returns private records: all of these are broken access control.
It tops the OWASP Top 10 because it is both widespread and high-impact. The controls that decide who can do what touch nearly every feature in an application, so a single missed check can expose an entire dataset.
What makes the category dangerous is that the application works perfectly for normal use. Nothing breaks, nothing errors out. The flaw only appears when someone probes the boundary the developers assumed no one would cross.
The Difference Between Access Control and Authorization
The access control vs authorization question sounds like pedantry, but the distinction shapes how you find and fix these bugs. Authorization is the policy: the set of rules describing which roles and users are allowed to do what. It is the intent.
Access control is the enforcement of that policy in running code, the checks that actually block a request when the rules say no. It is the implementation.
Most breaches in this category are not authorization failures. The policy is usually correct, at least on paper. The real problem is that the code never enforces it on a particular endpoint, or enforces it inconsistently. Knowing where policy ends and enforcement begins tells you where to look: the gaps live in the code, not the spec.
Where IDOR Fits Into the Broken Access Control Picture
Insecure Direct Object Reference, or IDOR, is a specific and very common broken access control flaw. It happens when an application exposes a reference to an internal object, like a database ID in a URL or API request, and fails to check whether the requesting user is actually allowed to access that object.
The classic example: a request for /invoices/1043 returns your invoice, so you try /invoices/1044 and get someone else’s. The application trusted the ID in the request instead of verifying ownership on the server. That single missing check is an idor vulnerability.
IDOR shows how broken access control usually works in practice. The problem is rarely an exotic exploit. It is a routine object lookup that skipped one authorization step, and it can lead to privilege escalation when the exposed object controls roles or permissions.
Preventing Broken Access Control
Start with deny-by-default. Every request should be denied unless something explicitly grants it, rather than allowed unless something blocks it. This flips the failure mode: a forgotten check locks people out instead of letting everyone in.
Enforce authorization on the server for every request, and verify ownership at the object level, not just the role level. Confirming a user is a “customer” is not enough if the endpoint never checks that the customer owns the specific record they asked for. Broken access control examples almost always trace back to a check that existed at one layer but was missing at another.
Testing is where these flaws actually surface. Because the vulnerability is logical, it takes an approach that understands who each user is supposed to be and deliberately tries to cross those boundaries. This is exactly the class of business logic and authorization gap that AI-driven offensive platforms like Novee are built to surface, and that teams increasingly evaluate alongside traditional tooling using an AI penetration testing buyer’s guide.
FAQ
Rarely on their own. Scanners are good at pattern-based bugs, but broken access control is a logic problem: it depends on who a user is and what they should own. A scanner cannot know your permission model, so it misses flaws like IDOR that require understanding intended access rules and testing across roles.
No. Broken access control appears anywhere permissions are enforced: REST and GraphQL APIs, mobile app backends, cloud storage buckets, internal services, and microservices talking to each other. APIs are an especially common target because they expose object references directly and are sometimes assumed to be hidden from users.
Authentication proves who you are, while access control governs what you can do once you are in. Broken authentication lets an attacker become someone they are not, like bypassing login. Broken access control lets an already-authenticated user reach things they should not. Different stage of the request, different fix.
Trusting input from the client to decide access. When an application uses an ID, role, or flag sent by the user to determine what they can reach, without re-checking it server-side, attackers simply change that value. Ownership and permissions must be verified on the server for every request, every time.