Cybersecurity glossary
What is Broken Access Control?
Learn what broken access control is in the OWASP Top 10, how BOLA and BFLA enable unauthorized data and function access, and how to enforce authorization correctly.
Definition
Broken Access Control is an OWASP Top 10 category (A01:2021) covering failures that let users act outside their intended permissions—viewing or changing other users’ data, elevating privileges, or invoking admin functions without proper authorization checks.
Why broken access control matters
If authorization fails, everything else is secondary. Broken Access Control (OWASP A01) is the Top 10 category most tied to real breaches: one missing check turns a normal account into a data dump or admin console.
APIs amplify the problem. Object IDs in paths and bodies invite horizontal privilege testing; “hidden” admin routes invite vertical escalation when the UI is the only gate.
How broken access control is exploited
Map reachable operations
Attackers enumerate endpoints, object IDs, and roles from clients, docs, or traffic.
Tamper with identity context
Swap resource IDs, roles, tenant headers, or tokens to probe enforcement gaps.
Hit missing or inconsistent checks
Some handlers verify ownership; others trust the client or only check authentication.
Read or change unauthorized assets
Data exfiltration, privilege escalation, or destructive admin actions follow.
Failure modes inside A01
BOLA / IDOR
Object access without proving the caller may use that specific resource ID.
BFLA
Privileged functions callable by lower-privilege roles because UI was the only filter.
CORS / force browsing
Mis-set cross-origin rules or guessable admin URLs exposing protected operations.
Metadata manipulation
JWT role claims, cookies, or hidden fields accepted as authoritative permissions.
Authorization controls that work
| Control | Notes |
|---|---|
| Deny by default | Every sensitive operation requires an explicit allow decision |
| Server-side checks | Re-validate ownership and role on each request; never trust the client |
| Central policy | Prefer shared authZ libraries or policy engines over one-off if statements |
| Tenant isolation | Scope queries and mutations by tenant/org as a hard invariant |
| Log denials | Alert on repeated authorization failures and admin function probes |
| Automated authZ tests | CI cases for horizontal and vertical privilege across critical APIs |
- Inventory sensitive objects and functions; document who may access each.
- Enforce object-level checks on every ID-parameterized read and write.
- Block privileged routes at the API layer for non-admin roles (not only in UI).
- Treat JWTs and cookies as identity, not as unsigned permission stores.
- Add tests that swap user A’s IDs while authenticated as user B.
- Review CORS and caching so authorized responses are not leaked cross-origin.
- Disable directory listing and force-browsable admin paths.
- Monitor for bursts of 403/401 on admin and cross-tenant resources.
The practical takeaway
Broken Access Control is unauthorized use of data or functions—OWASP’s #1 risk. Enforce authorization on the server for every request, cover BOLA and BFLA explicitly, and prove deny-by-default with automated privilege tests.
Related security terms
Broken Object Level Authorization (BOLA)
Missing or flawed checks on whether a caller may access a specific object.
Broken Function Level Authorization (BFLA)
Missing checks on whether a caller may invoke a privileged function or endpoint.
Broken Object Property Level Authorization (BOPLA)
Over-exposed or under-protected object fields in APIs.
Authorization
The broader discipline of deciding what an authenticated principal may do.
Frequently asked questions
What is broken access control in simple terms?
The app fails to enforce who can see or change what. A logged-in user reaches another user’s records, admin APIs, or actions their role should never allow.
Why is OWASP A01 ranked first?
Access control flaws are common, high-impact, and often easy to exploit once endpoints and IDs are mapped. They lead directly to data breaches and privilege escalation.
How do BOLA and BFLA relate?
BOLA (object-level) fails when object IDs are accessible without ownership checks. BFLA (function-level) fails when privileged operations lack role checks. Both are broken access control.
Is authentication enough?
No. Authentication proves identity. Access control (authorization) decides permissions. Many A01 bugs affect fully authenticated users.
Where do these bugs appear most?
APIs that accept resource IDs, mobile backends, multi-tenant SaaS, admin routes hidden only in the UI, and mass-assignment of role fields.
How should teams test for broken access control?
Test horizontal and vertical privilege cases: swap IDs across users, call admin endpoints as a normal user, and verify deny-by-default on every sensitive operation.
What is the primary defense pattern?
Enforce authorization on the server for every request, deny by default, centralize policy where possible, and never rely on UI hiding or unguessable IDs alone.
References
Explore authoritative guidance and frameworks related to broken access control.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.