The OWASP Top 10:2025 ranking explained — what moved, the two new categories, and how to continuously test each risk in modern apps and APIs.
TL;DR
The OWASP Top 10:2025 keeps Broken Access Control at #1 and adds two brand-new categories: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10). Security Misconfiguration jumps to #2, SSRF was consolidated into A01, and Insecure Design slipped to #6. The list spans 248 CWEs drawn from data on over 2.8 million applications. The practical lesson: risk increasingly lives in how components, pipelines, and identities are composed — so test continuously, map every finding to a category, and verify exploitability before you page anyone.
The OWASP Top 10 is the industry-standard awareness document ranking the most critical web application security risks, and the 2025 edition is the first major revision since 2021. Auditors reference it, security teams scope pentests around it, and engineering leaders use it to prioritize AppSec investment. Getting comfortable with the 2025 revision is the fastest way to align testing with what actually gets exploited today rather than what was common half a decade ago.
The 2025 list was built from a hybrid methodology: eight categories were selected directly from contributed testing data covering more than 2.8 million applications, and two were promoted via the OWASP community survey to capture emerging risks that automated tooling has not yet caught up to. In total, the list maps 248 CWEs across the ten categories — an average of roughly 25 weaknesses per category. That data-plus-expert-judgment blend is why the Top 10 remains a credible baseline rather than a popularity contest.
The biggest changes in 2025 are two new categories — Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10) — plus Security Misconfiguration climbing to #2 and SSRF being folded into Broken Access Control. If you learned the 2021 list, several of your mental shortcuts are now out of date. Here is the corrected mapping from 2021 to 2025.
| 2025 rank | Category | 2021 rank | Direction |
|---|---|---|---|
| A01:2025 | Broken Access Control | A01 | Steady (#1) |
| A02:2025 | Security Misconfiguration | A05 | Up |
| A03:2025 | Software Supply Chain Failures | A06 (expanded) | New / expanded |
| A04:2025 | Cryptographic Failures | A02 | Down |
| A05:2025 | Injection | A03 | Down |
| A06:2025 | Insecure Design | A04 | Down |
| A07:2025 | Authentication Failures | A07 | Steady (renamed) |
| A08:2025 | Software or Data Integrity Failures | A08 | Steady |
| A09:2025 | Security Logging and Alerting Failures | A09 | Steady (renamed) |
| A10:2025 | Mishandling of Exceptional Conditions | — | New |
A few reclassifications deserve emphasis, because they invalidate common assumptions:
Security Misconfiguration's jump to #2 tracks the shift to cloud-native and infrastructure-as-code. When a single misapplied Terraform module or over-permissive storage bucket policy can expose an entire environment, misconfiguration stops being a housekeeping issue and becomes a top-tier breach vector.
You test the 2025 categories continuously by wiring role-aware, deploy-triggered checks into CI/CD rather than relying on periodic scans. Point-in-time assessments miss the moments that matter — a new endpoint, a bumped dependency, a changed IAM role, a merged pull request. The table below pairs each category with a continuous-testing approach that fits a modern pipeline.
| Category | What to test continuously | Primary technique |
|---|---|---|
| A01 Broken Access Control | Authorization across roles and object IDs (IDOR); SSRF on outbound fetchers | Authenticated, role-aware DAST + IDOR fuzzing |
| A02 Security Misconfiguration | Cloud posture, headers, default creds, exposed admin panels | CSPM + IaC scanning + config diffing |
| A03 Software Supply Chain | Dependency CVEs, transitive deps, build/pipeline integrity | SBOM generation + diffing, Dependency-Track |
| A04 Cryptographic Failures | TLS config, weak ciphers, secrets at rest, hard-coded keys | Secret scanning + TLS/crypto probes |
| A05 Injection | SQL, NoSQL, command, template, XSS sinks | Parameterized DAST tuned per sink |
| A06 Insecure Design | Missing controls, abuse cases, business-logic flaws | Threat modeling + abuse-case testing |
| A07 Authentication Failures | Credential stuffing, weak MFA, session handling | Auth flow fuzzing + rate-limit checks |
| A08 Data Integrity Failures | Unsigned updates, insecure deserialization, CI trust | Signature verification + integrity checks |
| A09 Logging & Alerting | Coverage of security events; alert firing and routing | Detection validation / purple-team drills |
| A10 Mishandling of Exceptional Conditions | Error paths, fail-open logic, verbose errors | Fault injection + negative testing |
Broken Access Control stays #1 for a reason: scanners flag it poorly because authorization is business logic. In the 2025 data, 100% of tested applications had at least one form of broken access control. Test it with authenticated, role-aware sessions — not anonymous crawling — or you will miss the exact class of bug most likely to breach you.
Broken Access Control is the failure to enforce what an authenticated user is allowed to do, and it remains the #1 risk. It covers unauthorized disclosure, modification, or destruction of data, and now absorbs SSRF (CWE-918) and CSRF (CWE-352). With 40 mapped CWEs, an average incidence rate of roughly 3.73%, and a maximum near 20%, it is both the most prevalent and the hardest to catch with generic tooling. Test it by exercising every endpoint as multiple roles — anonymous, standard user, admin, and cross-tenant — and confirm that "deny by default" holds. Include functional access-control assertions in unit and integration tests so a broken check fails the build.
Security Misconfiguration is insecure default settings, incomplete hardening, and exposed surfaces, and it rose to #2. It maps 16 CWEs with an average incidence of about 3.00%. In cloud-native systems this means open storage buckets, permissive security groups, verbose error pages, unpatched default accounts, and missing security headers. Continuous testing here is CSPM plus infrastructure-as-code scanning: evaluate every Terraform/CloudFormation change before apply, and re-baseline running environments so drift is caught within hours.
Software Supply Chain Failures is the new #3 category covering compromises across dependencies, build systems, and distribution — not just known-vulnerable components. It expands 2021's A06 and, notably, carried the highest average incidence rate of any category at 5.19% in the contributed data. It also topped the community survey. Risk indicators include untracked transitive dependencies, no SBOM, CI/CD systems weaker than production, and simultaneous (rather than staged) rollouts. Test continuously by generating and diffing an SBOM on every build, wiring tools like OWASP Dependency-Track into CI, sourcing components only from trusted registries over secure links, and enforcing separation of duties so no single identity can push to production unchecked.
Cryptographic Failures is the exposure of data through weak, missing, or misapplied cryptography, and it dropped to #4. It maps 32 CWEs with an average incidence around 3.80%. The failures are rarely broken algorithms; they are missing TLS, weak cipher suites, hard-coded or reused keys, unsalted hashes, and sensitive data stored in the clear. Test with automated TLS and cipher probes, secret scanning across code and build artifacts, and checks that enforce encryption at rest and in transit as a policy gate.
Injection is untrusted input altering a command or query, and it moved down to #5. It still includes SQL, NoSQL, OS command, LDAP, expression-language, and cross-site scripting (XSS) sinks. The drop reflects maturing frameworks and parameterized queries, not disappearance. Test with DAST payloads tuned per sink and confirm that parameterization and output encoding hold on new endpoints — injection regressions often ride in on a single hand-built query.
Insecure Design is the absence of security controls by architecture rather than by bug, and it slipped from #4 to #6. No amount of clean implementation fixes a design that never required authorization on a sensitive workflow or never rate-limited a costly operation. Because there is no scanner for a missing control, this category is addressed through threat modeling, secure design reviews, and abuse-case testing that asks "how would an attacker misuse this feature as designed?"
Authentication Failures is the inability to reliably confirm identity, renamed from "Identification and Authentication Failures." It covers credential stuffing, weak or missing MFA, predictable session identifiers, and flawed password recovery. Test continuously with authentication-flow fuzzing, brute-force and credential-stuffing simulations against rate limits, and session-fixation and token-handling checks on every auth change.
Software or Data Integrity Failures is trusting code or data whose integrity was never verified. It includes insecure deserialization, unsigned or unverified auto-updates, and CI/CD pipelines that deploy artifacts without provenance. Test by verifying digital signatures on dependencies and updates, validating serialized objects, and asserting that only signed, attested artifacts can be promoted to production.
Security Logging and Alerting Failures is insufficient visibility and response, renamed to stress alerting over passive monitoring. Logs that no one reads and alerts that never fire are functionally invisible to an incident responder. Test detection the way you test code: run purple-team drills and detection-validation exercises that generate known-bad events and confirm the alert fires, routes to a human, and carries enough context to act.
Mishandling of Exceptional Conditions is the new #10 category for how systems behave under abnormal or error states. It maps 24 CWEs including CWE-209 (error messages leaking sensitive information), CWE-476 (NULL pointer dereference), and CWE-636 (failing open instead of closed). The core failure mode is a system that, when it breaks, breaks insecurely — granting access, skipping a check, or leaking a stack trace. Test with fault injection and negative testing: force timeouts, missing parameters, and downstream failures, then confirm the system fails closed and returns a safe, generic error.
Prioritize by verified, exploitable impact rather than by a finding's raw category rank. A confirmed IDOR exposing other tenants' records (A01) outranks a theoretical misconfiguration sitting behind three layers of auth (A02), even though both are high on the list. The ranking tells you where to invest testing effort; it does not tell you which of your findings to fix first.
Chain findings into attack paths so a "medium" that unlocks a "critical" gets the attention it deserves — an SSRF that reaches a cloud metadata endpoint and yields credentials is not a medium. Verify exploitability before you escalate, and let confirmed, chained impact drive the queue.
Map every finding to its OWASP 2025 category in your tracker. Over a quarter, the distribution tells you exactly where your secure-development lifecycle leaks — if half your confirmed issues are A01 and A02, the fix is guardrails in code and infrastructure, not another annual pentest.
For API-heavy systems, treat the OWASP Top 10 as a floor, not a ceiling. Pair it with the OWASP API Security Top 10, which digs deeper into broken object-level authorization (BOLA), broken function-level authorization, and mass assignment — the exact places where web-app assumptions break down against machine-to-machine traffic.
Not directly, but PCI DSS, SOC 2, and most customer security questionnaires expect you to test against it and remediate findings, which makes it a de facto baseline. Being able to show category-mapped coverage is often the fastest way to answer a security review.
A03:2025 Software Supply Chain Failures and A10:2025 Mishandling of Exceptional Conditions. A03 expands 2021's "Vulnerable and Outdated Components" to the entire build-and-distribution ecosystem; A10 is entirely new and covers error handling, logic errors, and fail-open behavior.
Server-Side Request Forgery was a standalone category (A10:2021) but was consolidated into A01:2025 Broken Access Control as a notable weakness, CWE-918. It is now framed as an authorization failure over server-side outbound requests rather than a category of its own.
No. Insecure Design dropped from #4 in 2021 to #6 in 2025. It remains important — design flaws cannot be scanned away — but it did not climb the ranking.
Partially. For API-heavy systems, pair it with the OWASP API Security Top 10, which covers object-level authorization, function-level authorization, and mass assignment in far more depth than the general web list.
Continuously. Tie testing to deploys and dependency changes so new risk is caught in hours, not at the next annual assessment. Access control and misconfiguration especially benefit from role-aware checks on every release.
248 CWEs across the ten categories, an average of about 25 per category, derived from contributed data on more than 2.8 million applications plus a community survey for two of the ten.
The categories move between editions, but the durable habit does not: test every category continuously against realistic, authenticated conditions, and verify that a finding is genuinely exploitable before it becomes an alert. That is what turns the OWASP Top 10 from a checklist into a measure of whether your defenses actually hold.
Automated penetration testing gives speed and continuous coverage; manual testing gives depth and creativity. Compare the two, see where each wins, and how to combine them.
Penetration Testing as a Service (PTaaS) delivers pentesting through a continuous platform instead of a once-a-year PDF. Compare cost, cadence, coverage, and when each model wins.
S3 buckets go public through policies, ACLs, and disabled Block Public Access. Learn the layered defense model, hardening checklist, and CLI remediation.