If you searched for the "OWASP Top 10 2026", here is the short answer: there isn't one. The current edition is OWASP Top 10:2025 — the eighth installment, announced at the Global AppSec conference in November 2025 and finalised in January 2026. It is the first update since 2021.
The confusion is understandable. OWASP does not publish annually, releases are named for the year the data analysis concludes rather than the year they land, and the 2025 edition was finalised in early 2026. This guide covers what the current list actually contains, what changed since 2021, how the list is built, and where to start if you cannot address all ten at once.
Is There an OWASP Top 10 2026?
No. OWASP Top 10:2025 is current, and there is no announced successor. Editions have historically arrived every three to four years — 2013, 2017, 2021, 2025 — so the next one is unlikely before 2028 or 2029.
This matters practically. If a vendor proposal, an internal policy document or an auditor's checklist references an "OWASP Top 10 2026", it is citing something that does not exist. The same applied to the widely referenced but non-existent 2024 edition. Check that your security documentation names the 2025 list, because a control mapped to a phantom standard is a finding waiting to happen.
What Changed Since 2021
The 2025 revision is more substantial than a reshuffle. Two categories are new, one was absorbed into another, and several moved significantly.
| Change | Detail |
|---|---|
| New | A03 Software Supply Chain Failures — an expansion of the old "Vulnerable and Outdated Components" |
| New | A10 Mishandling of Exceptional Conditions — error handling, logic failures, failing open |
| Absorbed | SSRF was its own category in 2021. It now sits inside A01 Broken Access Control |
| Moved up | Security Misconfiguration, from #5 to #2 |
| Moved down | Cryptographic Failures #2 to #4 · Injection #3 to #5 · Insecure Design #4 to #6 |
| Renamed | A07 is now Authentication Failures · A09 is now Security Logging and Alerting Failures — alerting, not just monitoring |
Two of those deserve comment.
The A09 rename is not cosmetic. Changing "monitoring" to "alerting" reflects a real pattern: organisations that log diligently, retain everything, and still take weeks to notice a breach because nothing ever fires. Collection is not detection.
Security Misconfiguration climbing to #2 tracks how infrastructure is now built. When environments are declared in code and provisioned automatically, a single bad default propagates everywhere at once. The upside is that the fix propagates just as fast — which is why this category tends to offer the best return on effort.
The OWASP Top 10:2025 in Full
A01 — Broken Access Control
Remains at number one, appearing in roughly 3.73% of applications tested, with about 40 mapped CWEs. This is the category that now includes SSRF, and it covers everything from missing function-level checks to object-level authorisation failures where a user can read another user's records by changing an ID.
Access control cannot be tested reliably by scanners, because a scanner does not know that order 1234 belongs to a different customer. This is the single strongest argument for manual testing in any security programme.
A02 — Security Misconfiguration
Up from fifth, present in around 3.00% of applications. Default credentials, unnecessary features enabled, permissive cloud storage, verbose error pages, missing hardening. In cloud environments this is largely an infrastructure-as-code problem, which makes it well suited to automated policy enforcement.
A03 — Software Supply Chain Failures
New, and the most interesting entry in the list. It broadens the old dependency-focused category to cover the whole chain: packages, build systems, CI/CD pipelines, and the tooling that produces your artifacts.
Notably, it has the fewest occurrences in the underlying data but the highest average exploit and impact scores among mapped CVEs, and it was voted the top concern in the community survey. Rare, but when it happens it is severe — and a compromised build pipeline ships to every customer simultaneously.
A04 — Cryptographic Failures
Down from second, in about 3.80% of applications with roughly 32 CWEs. Weak algorithms, poor key management, data transmitted or stored unencrypted. The drop in ranking reflects improved defaults across frameworks and cloud services rather than the problem being solved.
A05 — Injection
Down from third, with about 38 CWEs — and still the category with the most CVEs of any on the list. It spans a wide range, from cross-site scripting (frequent, usually lower impact) to SQL injection (rarer now, potentially catastrophic). Modern frameworks parameterise queries by default, which is why the ranking fell even as the raw CVE count stayed high.
A06 — Insecure Design
Down from fourth. Introduced in 2021 to capture flaws that no amount of correct implementation can fix — a password reset flow that is fundamentally guessable, a business process with no rate limiting by design. These are found through threat modelling, not testing.
A07 — Authentication Failures
Stable at seventh, renamed from "Identification and Authentication Failures", with around 36 CWEs. Credential stuffing, weak session management, flawed recovery flows, missing multi-factor authentication on privileged accounts.
A08 — Software or Data Integrity Failures
Stable at eighth. Trust boundary violations at a lower level than the supply chain category — insecure deserialization, unsigned updates, CI/CD pipelines that accept unverified input.
A09 — Security Logging and Alerting Failures
Stable at ninth, with the meaningful rename discussed above. Insufficient logging, logs that lack the context needed for investigation, and — critically — alerting that never fires.
A10 — Mishandling of Exceptional Conditions
New, with 24 mapped CWEs. Improper error handling, logic errors in edge cases, and systems that fail open rather than closed. The classic example is an authorisation check that throws an exception and, in the catch block, grants access.
This is a genuinely useful addition because it names a class of bug that engineers recognise immediately but that had no home in previous editions.
Where to Start
Ten categories is too many to attack simultaneously. A defensible order for most teams:
Access control first, because it is number one on prevalence and because the failures are usually severe and directly exploitable.
Configuration second, because it is the cheapest to fix at scale. Policy-as-code in your pipeline closes a whole class of issue permanently rather than one instance at a time.
Supply chain third, because the impact scores are the highest on the list even though incidence is low. Dependency scanning, artifact signing and build pipeline hardening.
Then work down. The ordering is not sacred — if you handle payment data, cryptographic failures move up; if you have had an incident nobody noticed, logging and alerting moves up.
How the List Is Actually Built
Understanding the methodology helps you use the list correctly rather than treating it as a compliance checklist.
The 2025 edition analysed 589 CWEs, of which 248 were mapped into the ten categories — an average of roughly 25 per category, capped at 40. That is a substantial widening from earlier editions, which is why individual entries feel broader than they used to.
The data comes from around 175,000 CVE records and contributions covering approximately 2.8 million applications. Eight of the ten categories were derived from that data. Two came from a community survey, on the reasoning that practitioners see emerging risks before they show up in historical incident data.
Two implications worth holding onto. First, the ranking reflects what is commonly found, not what is most dangerous to your application — a category at #8 may be your single biggest risk. Second, because contributed data comes largely from organisations that test, it skews toward applications that already receive security attention.
Using the List Properly
The most common mistake is treating the Top 10 as a certification target. It is an awareness document. OWASP itself positions it as a starting point rather than a standard, and it does not claim completeness.
Three ways to get real value from it:
- Map it to your pipeline, not your report. Most categories can be partially addressed by automated checks — dependency scanning for A03, IaC policy for A02, SAST for A05. That is DevSecOps work, and it prevents recurrence rather than cataloguing it.
- Use it to scope testing, not replace it. A01, A06 and A10 need a human. Access control, design flaws and edge-case logic are exactly what automated tools miss. A VAPT audit is where those get found.
- Do not stop at ten. The list covers common categories, not your specific architecture. Business logic flaws unique to your product will never appear on any generic list.
Related Lists Worth Knowing
The flagship Top 10 covers web applications. OWASP maintains separate lists for other contexts, and confusing them causes real scoping errors:
- OWASP API Security Top 10 — object-level and function-level authorisation failures dominate. If you ship APIs, this list matters more than the web one.
- OWASP Mobile Top 10 — platform-specific concerns around storage, binary protection and inter-process communication.
- OWASP Top 10 for LLM Applications — prompt injection, training data poisoning and related risks. Increasingly relevant as teams ship AI features.
If your product is API-first, scoping a security engagement against the web Top 10 alone will leave your largest attack surface untested.
Turning the List into Action
The categories that automation handles well — configuration, dependencies, injection — belong in your pipeline as gates, so they never reach production. Our cloud security and DevSecOps consulting practices cover that side, and our AWS security checklist for HIPAA, SOC 2 and PCI-DSS maps many of these controls to compliance requirements.
The categories that need a human — access control, insecure design, exceptional conditions — need testing. If you want your application assessed against the current list by people rather than a scanner, review our VAPT services or talk to our team. We will scope it against the parts of the list that actually apply to your architecture, rather than running a generic checklist against everything.
