The OWASP Top 10 (2021): what changed and why it matters

A logged-in user opens their invoice at GET /api/invoices/4815 and, out of boredom, edits the URL to 4816. It loads — someone else’s invoice, with their name, address, and card last-four. No exploit kit, no SQL, no payload. Just an integer the server trusted because the request had a valid session cookie. This is IDOR, the textbook face of Broken Access Control — and in OWASP’s 2021 data it sat at the top of the list, found in 94% of every application tested.

What the Top 10 actually is

The OWASP Top 10 is not a checklist of bugs — it is a data-driven ranking of the categories of risk that most often appear in real web applications. The 2021 edition was built from contributed data covering more than 500,000 applications across a dozen organizations: eight of the ten categories came straight from that data, and two were added from a community survey to capture risks that tooling is too young to have measured yet. That last detail matters more than it sounds: it is why a category can rank without huge historical numbers behind it.

The single biggest change in 2021 was philosophical. The list reorganized around root causes instead of symptoms. “Sensitive Data Exposure” — the old #3 — described what you saw after a breach. Its replacement, “Cryptographic Failures,” names what actually went wrong: weak crypto, missing TLS, hardcoded keys. The whole list was re-derived against roughly 400 mapped CWEs (up from about 30), so a category now groups a real failure mode you can design against, not an outcome you notice too late.

Broken Access Control: the new #1

Access control answers one question: is this authenticated user allowed to do this specific thing to this specific resource? When the answer is computed wrong — or never computed — you get Broken Access Control. It rose from #5 in 2017 to #1 in 2021, mapping 34 CWEs, with the highest number of occurrences in the dataset of any category. The headline number: 94% of applications tested showed some form of broken access control. It is simultaneously the most common and one of the most serious classes.

Two failure shapes dominate in production:

• IDOR (Insecure Direct Object Reference): the server uses a client-supplied id to fetch a record but never checks that the record belongs to the caller. GET /api/invoices/4816 returns a stranger’s invoice because the query was WHERE id = ? and not WHERE id = ? AND owner_id = ?.
• Missing function-level authorization: the UI hides the admin button, so nobody guards the endpoint. A non-admin who sends POST /api/admin/users/{id}/promote directly gets promoted, because the only “check” was that the link was invisible.

The senior reflex is deny by default: every resource access starts from “no,” and authorization is enforced server-side on the actual record and action — never inferred from a hidden UI element, a JWT claim the client could forge, or the mere presence of a session.

The new design-era categories

Two additions in 2021 mark the field maturing past “scrub the input.” Insecure Design (A04) is the recognition that some vulnerabilities are baked in before a single line is written — a password-reset flow with no rate limit, a checkout that trusts a client-sent price. You cannot patch your way out of a flawed design; the fix is shift-left: threat-model the feature, write abuse cases alongside user stories, and bake the control into the architecture. It is the difference between a coding mistake and a missing security requirement.

SSRF (A10) is the standout for a different reason: it had almost no historical data — it maps essentially a single CWE — yet it ranked, because practitioners voted it in through the community survey. SSRF is when your server can be tricked into making a request to a URL the attacker controls: a “fetch this image” feature pointed at http://169.254.169.254/ to read cloud metadata credentials. Its presence on the list, ahead of better-documented bugs, is the clearest signal that the Top 10 tracks where the field is heading, not just where the old scanners have already been.

How a senior reads the list

The ranking is a prioritization tool, not gospel. A senior reads it as “where is my time best spent,” and access control wins on expected value: it is the most common class and among the most damaging, so it earns the most rigor — server-side checks on every object and every function, written as deny-by-default. Treat the rest as a coverage map: crypto in transit and at rest, parameterized data access, a dependency-update process so A06 doesn’t accumulate silently, hardened configs, and structured security logging so you can even detect the breach you didn’t prevent.