OWASP Top 10 2025: What Actually Changed (and What It Means for You)

The OWASP Top 10 does not change often. It was updated in 2013, 2017 and 2021, and each revision quietly rewrites what a lot of security programmes measure themselves against — because the list ends up embedded in pentest report templates, compliance checklists, training curricula and procurement questionnaires long after it is published.

The 2025 edition was announced at OWASP Global AppSec in Washington, D.C. in November 2025 and finalised in January 2026. It is not a cosmetic refresh. Two categories are new, one disappeared as a standalone entry, two were renamed, and the reshuffle at the top says something specific about how applications are actually being broken into.

The whole change, in one picture

Every 2021 category still exists somewhere in 2025 — nothing was deleted outright. What changed is rank, grouping and naming:

The methodology behind it is worth a sentence, because it is the reason to take the reordering seriously rather than treat it as opinion. The 2025 list draws on roughly 175,000 CVE records mapped to CWEs, out of a pool of nearly 220,000 CVEs and 643 distinct weakness types, alongside testing data covering more than 2.8 million applications. The final ten categories bundle 248 CWEs between them.

Change 1: Security Misconfiguration jumped from #5 to #2

This is the single loudest signal in the 2025 list, and it is not because developers got worse at configuring things. It is because there is vastly more configuration to get wrong, and it changes far more often than it used to.

A 2015 application had a web server config and a framework settings file. A 2026 application has those plus container manifests, a service mesh, IAM policies, feature flags, CDN rules, storage bucket ACLs, CORS policy, security headers, and a stack of managed services each with its own permission model. Every deploy is a chance to expose something, and continuous deployment means deploys are constant.

Change 2: Software Supply Chain Failures is the new A03

In 2021 this category was “Vulnerable and Outdated Components”, and it meant one thing in practice: you are running a library with a known CVE, so patch it. Real supply chain attacks moved well past that.

A03:2025 widens the category to the entire path your code takes from a developer's machine to production — dependencies and their transitive dependencies, the build system, the CI runner, the artefact registry, the distribution channel. Any of them can be compromised without a single line of your own repository being touched.

The reason this earned promotion to third place is that the attack economics are excellent for the attacker. Compromising one popular package, or one build server, reaches every downstream consumer at once. Compromising your application reaches your application.

• —Dependency confusion — publishing a public package with the same name as a company's private one, and letting the resolver pick the wrong one.
• —Typosquatting — a package one keystroke away from something popular.
• —Maintainer takeover — a real, trusted package that ships clean for months and then does not, once its publish credentials change hands.
• —Build system compromise — the source is clean, the artefact is not, because something was injected between them.

Change 3: SSRF is gone as a category — and that is a promotion

SSRF entered the list in 2021 at A10, added largely because the community survey demanded it. In 2025 it does not appear as its own entry. That reads like a demotion and is the opposite.

SSRF has been folded into A01 Broken Access Control, which stayed at number one. The reasoning is that SSRF is rarely interesting for its own sake — it is interesting because it lets an attacker reach something they should not be able to reach. That is an access control failure whose vehicle happens to be a URL your server fetches. Cloud metadata endpoints, internal admin services, databases bound to localhost: all reached, all off-limits, all access control.

Change 4: A10 Mishandling of Exceptional Conditions is brand new

The genuinely new entry, and the most interesting one, because it is not a vulnerability class in the usual sense. It is a category about what your application does when something goes wrong — 24 CWEs covering improper error handling, logic that fails open, unhandled edge cases, and states nobody designed for.

Most security testing exercises the paths a developer intended. This category is about the paths nobody intended:

• —An authentication check that throws an exception, and the catch block lets the request continue.
• —A rate limiter that fails open when its backing store is unreachable — so the way to defeat it is to break it.
• —A stack trace returned to the user containing file paths, framework versions and query fragments.
• —A payment flow interrupted midway that leaves an order marked paid.

Change 5: two renames that are more than cosmetic

The logging rename is the one worth internalising. Plenty of teams satisfied the 2021 wording by shipping logs somewhere and calling it monitoring. The 2025 wording asks a harder question: when this fires at 3am, does anyone find out?

What to actually do about it

The part that has not changed

Broken Access Control has been number one since 2021 and remains number one, now larger than before. Injection dropped to fifth, which is not evidence that injection is solved — it reflects that frameworks increasingly make the safe pattern the default one, while access control remains something every application has to get right by hand, endpoint by endpoint, with no framework able to decide for you who should see what.

That is the thread running through the whole 2025 revision. The categories that rose are the ones no library fixes for you: how your system is configured, where your code comes from, who is allowed to touch what, and what happens when it breaks.