Broken Access Control: The Flaw That Now Tops the OWASP List

In the 2021 revision of the OWASP Top 10, Broken Access Control climbed to the number-one spot, overtaking injection after years at the top. The reason is unglamorous: OWASP found that 94% of the applications tested had some form of broken access control, making it the most commonly encountered category in the data. It is the flaw of a system that knows who you are and forgets to ask what you are allowed to do.

Access control enforces the boundary between what a user can do and what they should be able to do. When that boundary fails, an authenticated user acts outside their intended permissions — reading other people's records, editing data they don't own, or reaching administrative functions never meant for them. The failure is rarely exotic. It is usually a check that was omitted, applied in the wrong place, or trusted to the client.

What it looks like in practice

The classic form is the insecure direct object reference (IDOR): an endpoint accepts an object identifier and returns the object without confirming the caller owns it. Change account=123 to account=124 and read a stranger's statement. Related failures include privilege escalation — acting as an administrator by manipulating a role field or forcing your way to an admin URL — and metadata tampering, where a token or cookie is replayed or elevated to grant rights it should not carry.

A large share of these flaws come from a single assumption: that because the UI never shows a control to a normal user, the server never needs to defend it. Attackers do not use your UI. They call your endpoints directly, and any authorization decision made only in the browser is no decision at all.

Getting it right

• Deny by default. Every resource except explicitly public ones should reject access unless a rule grants it. Fail closed, not open.
• Enforce on the server, on every request. Re-verify authorization for each object and each function server-side. The client's view of what a user may do is a convenience, never a control.
• Centralise the mechanism. Route access decisions through one shared component rather than scattering per-endpoint checks a developer can forget on the next handler.
• Derive scope from the session. Where you can, query by the authenticated principal (WHERE owner_id = :me) instead of accepting an arbitrary ID and checking afterward.
• Log failures and rate-limit. Repeated access-denied events are a probing signal; alert on them and slow down enumeration.
• Test authorization continuously. Replay one user's requests with another user's token in automated tests to catch regressions before they ship.

Broken access control is a discipline problem more than a technical one. The individual fix — an ownership check, a role gate — is trivial; the difficulty is applying it without exception across an application that keeps growing new endpoints. That invariant erodes silently, which is why you cannot defend an attack surface you have never fully inventoried.