Broken Access Control, Explained
Broken access control is the failure to enforce what an authenticated user is allowed to do — and it is the number-one risk in the OWASP Top 10. The user is correctly identified, then the application forgets to check whether they may perform this action on this object. The result ranges from reading a stranger’s records to acting as an administrator.
What does broken access control look like?#
It appears in recognizable patterns:
| Pattern | Example |
|---|---|
| IDOR | Changing an ID to reach another user’s data |
| Missing function-level checks | A normal user calling an admin-only endpoint |
| Forced browsing | Reaching hidden pages by guessing URLs |
| Metadata tampering | Editing a role in a JWT or hidden field |
| CORS misconfig | Exposing an API to unauthorized origins |
All share one root: the app decided who you are but not what you may do — the authentication vs authorization gap at scale.
Why is it the most common serious flaw?#
Because authorization is decentralized. Authentication happens once and reuses a library; authorization must be enforced on every endpoint, for every object, according to business rules a framework cannot know. Every new route is a new opportunity to omit a check — and an omitted check does not throw an error, it silently allows.
How do you enforce access control?#
- Deny by default — fail-safe defaults: no access unless explicitly granted.
- Check on the server, every time — never trust client-side enforcement.
- Enforce at the object level — confirm ownership of the specific record.
- Centralize the logic — a shared authorization layer, so checks are consistent, not copy-pasted.
Broken access control is the enforcement side of authorization, closely tied to IDOR and SSRF. More at the Web Security hub.
Frequently asked questions#
What is broken access control?
Broken access control is any failure to enforce what an authenticated user is allowed to do. It covers accessing other users’ data, reaching admin functions as a regular user, and bypassing intended restrictions. It sits at number one in the OWASP Top 10 because the checks are bespoke, easy to forget, and invisible in normal testing.
Why is access control so hard to get right?
Because it is scattered across every endpoint and depends on business rules, not a single library call. Authentication is centralized and reusable; authorization must be decided per action and per object. Every new endpoint is a fresh chance to forget a check, and missing checks fail silently until someone probes them.