The OWASP Top 10 is the reference document that catalogues the ten most critical security risks to web applications. Its new edition — the OWASP Top 10 2025 — was announced in November 2025 at the OWASP Global AppSec conference in Washington, D.C., and finalised in January 2026. It is the first major revision since 2021. That four-year gap is a window during which a substantial share of developer-training programmes, static-analysis rules wired into CI/CD pipelines and internal audit checklists has stayed aligned to a threat map that recent data now contradicts.

If your last developer-awareness cycle predates 2025, there's a good chance it omits two risk categories that are now explicitly listed, and that it still places injection third when it has in fact dropped. Understanding how these risks have shifted directly determines how effective any application security programme can be.

• First major revision since 2021, drawing on more than 175,000 CVEs analysed. In total, 589 CWEs were examined (against roughly 400 in 2021), of which 248 were mapped into the final ten categories.

• Two new categories enter the list: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10).

• SSRF (Server-Side Request Forgery) no longer exists as a standalone category: it has been absorbed into Broken Access Control (A01).

• Security Misconfiguration jumps from 5th to 2nd; Injection falls from 3rd to 5th.

• Broken Access Control remains at the top, for the fourth consecutive edition.

The 2025 list keeps its ten-category structure, each identified by its code (A01–A10) and its official name:

• A01 — Broken Access Control — was A01 in 2021. Stable, top of the list for four editions; now absorbs SSRF.

• A02 — Security Misconfiguration — was A05. Up three places.

• A03 — Software Supply Chain Failures — new category, an expansion of A06:2021.

• A04 — Cryptographic Failures — was A02. Down two places.

• A05 — Injection — was A03. Down two places.

• A06 — Insecure Design — was A04. Down two places.

• A07 — Authentication Failures — was A07. Stable.

• A08 — Software and Data Integrity Failures — was A08. Stable.

• A09 — Security Logging and Alerting Failures — was A09. Renamed (Monitoring → Alerting).

• A10 — Mishandling of Exceptional Conditions — new category, replaces SSRF.

The ranking is not driven by data alone. OWASP first ordered its categories from the contributed data, then reserved two of the ten places for risks highlighted by its community survey — even where those risks remain under-represented in the data. The reasoning is deliberate: analysing data means looking at the past. Between the moment a new class of vulnerability emerges and the moment the industry can test for it at scale, years often pass. That lag is precisely what explains the arrival of supply chain and exceptional-conditions failures.

This is the sharpest move in the ranking, and it says something specific about how modern applications are deployed. According to OWASP's data, roughly 3% of tested applications carried at least one of the 16 CWEs in this category — a prevalence high enough this cycle to push security misconfiguration ahead of cryptographic failures.

What security misconfiguration covers is rarely sophisticated: cloud buckets left publicly accessible, default accounts never disabled, misconfigured HTTP headers, overly verbose error messages that expose internal architecture. None of these flaws demands an elaborate attack — only a look at what was missed during configuration.

The structural cause of this rise is the imbalance between continuous deployment and continuous checking. As application behaviour shifts into configuration files, cloud permissions and infrastructure-as-code (IaC) templates, every mis-set flag becomes a potential vector. An organisation that ships to production several times a day but audits its configurations only once a quarter mechanically creates a live exposure window between checks. The faster the deployment cadence, the wider that window grows if monitoring doesn't keep pace.

The new A03 category expands what was called "vulnerable and outdated components" in 2021 to cover the entire ecosystem that builds, distributes and updates software: a compromised dependency, an unsigned update, an infiltrated build pipeline, a hijacked registry.

Here's the point many write-ups miss — and the most instructive one. In OWASP's data, supply chain shows the lowest number of occurrences in the ranking, because it remains hard to test for at scale. Yet this category was overwhelmingly voted a top concern in the community survey, and the CVEs attached to it carry the highest average exploit and impact scores in the entire Top 10. In other words: supply-chain risk structurally outruns the tools meant to detect it. OWASP made the deliberate choice to promote this category despite its under-representation in the data, because practitioners on the ground could already see it coming.

The 2025–2026 numbers prove them right, and dramatically so:

• The Sonatype 2026 State of the Software Supply Chain report counts more than 454,600 new malicious open-source packages in 2025, a 75% year-on-year increase, for a cumulative total above 1.23 million blocked packages. More than 99% of this malware sits on npm.

• The Verizon DBIR 2025 finds that 30% of breaches now involve a third party, double the 15% of the previous year — the largest single-year jump in the report's history.

• According to the IBM Cost of a Data Breach 2025, a supply chain compromise costs $4.91M on average and takes 267 days to identify and contain — the longest lifecycle of any vector tracked.

The Shai-Hulud worm, which surfaced on npm in September 2025, marked a turning point: the first self-replicating malware native to a registry, it steals maintainers' tokens to automatically republish poisoned versions of all their packages. Its successive waves — "Second Coming" in late 2025, Mini Shai-Hulud in spring 2026, then variants such as Miasma and the June 2026 Red Hat incident — compromised thousands of packages and exposed tens of thousands of downstream repositories. The threat landed close to home in the UK: NHS England issued a cyber alert over the April–May 2026 npm/PyPI waves, and the NCSC has urged organisations to audit their dependencies in response to this class of attack.

Two takeaways for 2026, both extending OWASP's own point directly:

1. The most significant supply-chain attacks carry no CVE at the time they're exploited. The Trivy incident is emblematic: a vulnerability scanner itself hijacked to distribute credential theft across thousands of CI/CD workflows, whose CVE (CVE-2026-33634) was only assigned and added to the CISA KEV catalogue after the fact. A programme that audits only already-catalogued vulnerabilities is structurally always behind.

2. AI is becoming an attack surface in its own right. The ENISA Threat Landscape 2025 documents model poisoning, "Rules File Backdoor" attacks against AI coding assistants, and slopsquatting — registering packages under names hallucinated by LLMs, which developers then install without checking.

The second new category, A10, gathers 24 CWEs covering failures that arise when an application meets an unexpected situation and handles it badly: an uncaught exception that reveals a full stack trace to the user, a race condition that corrupts internal state, a mechanism that "fails open" and grants access on error.

The risk lies less in the error occurring than in the absence of a prepared response. Developers naturally focus their testing on the happy paths — valid inputs, expected behaviour. Attackers, by contrast, live in the edge cases: they probe what happens when a system fails. That gap is exactly what the A10 category names.

The A10 category replaces SSRF in tenth position. SSRF hasn't vanished from the framework, though: it has been absorbed into Broken Access Control (A01), OWASP now treating it as fundamentally an access-control failure rather than a standalone risk. The defensive practices are unchanged: allowlisting outbound destinations, restricting access to cloud metadata, validating URL schemes.

If your AppSec programme is still pinned to the 2021 framework, three adjustments are due.

Your static-analysis rules need remapping. Rules that pointed to SSRF under A10:2021 must now sit under A01:2025, and new rules covering supply chain and exception handling must be switched on. The main SAST vendors (Parasoft, Semgrep and others) have already shipped compliance packs updated for 2025; relying on SAST without this update means auditing your code against a map that's four years out of date.

Your dependency scanning needs to extend across the whole chain. Classic software composition analysis (SCA), focused only on already-catalogued vulnerabilities, no longer suffices. You now need to add SBOM generation (the exhaustive inventory of an application's software components), dependency signature verification, and heightened vigilance around dependency confusion, typosquatting and slopsquatting. A note of caution: provenance verification (SLSA-style) remains necessary but is no longer sufficient — some Shai-Hulud waves produced packages with valid provenance. Behavioural analysis at install time becomes decisive.

Your code review needs a checklist for exceptional conditions. Uncaught exceptions, race conditions, TOCTOU anomalies, error-handling policy: these are now explicitly named risks that reviewers must check systematically rather than on a hunch. Adopting secure design patterns from the design stage structurally reduces exposure to both new categories.

In practice, it's precisely the gap between what the code claims to cover and what proves actually exploitable from the outside that justifies continuous monitoring rather than an audit tied to OWASP's publication cycle. Dynamic testing (DAST) deployed continuously detects a misconfiguration or an access failure the moment it becomes exploitable, without waiting for the next revision of the framework. It's also the most direct way to reduce the risk of sensitive data exposure — the most common consequence of the majority of categories on this list.

"OWASP's Top 10 remains an awareness document, not a complete compliance framework. The real work begins once you've read it: checking that what you think you cover matches what is actually exposed across your perimeter."
— Vladimir Kolla, co-founder of Patrowl

The OWASP Top 10 2025 doesn't merely reshuffle a ranking. It marks a deeper shift: application security is no longer played out solely in the code you write, but in how that code is built, in the dependencies you choose, and in the configuration of your deployment infrastructure. The two new categories aren't cosmetic additions — they document attacks already happening in production, as the Shai-Hulud waves and the explosion of malicious packages in 2025–2026 confirm.

Updating your scan rules, your developer training and your code-review priorities is therefore not a box-ticking compliance exercise. It's about aligning your application security programme with a threat map that is, in fact, four years out of date if it hasn't moved since 2021.

How often is the OWASP Top 10 updated?
Roughly every three to four years. Previous editions date from 2003, 2004, 2007, 2010, 2013, 2017 and 2021. The 2025 edition is the eighth.

What are the two new categories in the Top 10 2025?
Software Supply Chain Failures (A03), which expands the former vulnerable-components category, and Mishandling of Exceptional Conditions (A10), covering uncaught exceptions, race conditions and absent error-handling policies.

What happened to SSRF in the Top 10 2025?
SSRF has been absorbed into Broken Access Control (A01), OWASP treating it as fundamentally an access-control failure. The defensive practices are unchanged: allowlisting outbound destinations, restricting access to cloud metadata, validating URL schemes.

Why did security misconfiguration move from 5th to 2nd place?
Because its prevalence rose this data cycle (around 3% of tested applications carried at least one of its CWEs) and because continuous deployment without continuous checking creates an exposure window that widens with deployment cadence and the spread of infrastructure as code.

Why is supply chain ranked so high when it's barely present in the data?
Because OWASP doesn't rely on historical data alone. Supply chain shows few occurrences (it remains hard to test for), but its associated CVEs carry the highest exploit and impact scores in the ranking, and the category was strongly backed by the community survey. The 2025–2026 figures confirm the call: +75% malicious open-source packages in a single year, per Sonatype.

Is the OWASP Top 10 a compliance standard?
No. OWASP presents it as an awareness document, not a complete framework. Standards such as PCI DSS 4.0 and SOC 2 recognise OWASP Top 10 coverage as evidence of secure coding practices, and in the UK the NCSC's secure-development guidance and the security obligations under UK GDPR point in the same direction. To go further, OWASP recommends maturity models such as SAMM, DSOMM or ASVS.

Sources: OWASP Top 10:2025 (owasp.org/Top10/2025) · Sonatype 2026 State of the Software Supply Chain Report · Verizon 2025 DBIR · IBM Cost of a Data Breach 2025 · ENISA Threat Landscape 2025 · NCSC · NHS England · Unit 42 (Palo Alto Networks), Parasoft, Semgrep, GitLab, Fluid Attacks.