OWASP Top 10:2025 — What Each Risk Category Actually Covers#

The OWASP Top 10 is an awareness document, not a standard, not a test plan, and not a compliance checklist. It represents a broad consensus about the most critical risks to web applications, built from contributed data plus a community survey. Treat it as a shared vocabulary for prioritising risk, and reach for ASVS when you need verifiable requirements.

This edition is OWASP Top 10:2025. Before you read any of the ten categories below, note what actually moved from the 2021 edition — because a page written against the old list will name categories that no longer exist:

• A03 Software Supply Chain Failures is new, and it broadens the old "Vulnerable and Outdated Components" risk into all supply chain failures: a malicious maintainer, a compromised build system, a poisoned CI/CD pipeline, an artifact that is rebuilt instead of promoted.
• A10 Mishandling of Exceptional Conditions is new: fail-open logic, unhandled exceptions, error messages that leak, and unreleased resources.
• Server-Side Request Forgery (SSRF) is no longer a standalone category. Its CWE (CWE-918) now sits inside A01 Broken Access Control.
• A09 is now "Security Logging and Alerting Failures" — the rename makes the point that logging without alerting changes nothing.
• A07 dropped "Identification and" and is now simply "Authentication Failures".

The ten categories at a glance#

A01:2025 — Broken Access Control#

Access control enforces policy so that users cannot act outside their intended permissions. It stays at #1, and in the contributed data every application tested had some form of it. It covers insecure direct object references (IDOR/BOLA), forced browsing, missing function-level checks on POST/PUT/DELETE, privilege escalation, JWT tampering and replay, CORS misconfiguration, and — as of 2025 — SSRF, because a request the server makes on your behalf is still an authorisation decision about which destinations are in scope.

Test signal: for every object and every action, prove both an allow (own resource) and a deny (foreign resource) case. A route that rejects an outsider entirely has not exercised its object-level policy — it has only tested function-level access. This is exactly the gap the site walks through in the API access control test plan, the IDOR/BOLA test plan, and its automation in the BOLA test matrix.

A02:2025 — Security Misconfiguration#

This category moves up to #2, and its definition is deliberately broad: any part of the stack set up insecurely. Default accounts and passwords left in place, unnecessary features, ports, or sample apps enabled, verbose stack traces returned to users, missing security headers, permissive cloud storage, and security features disabled on upgraded systems.

Test signal: enumerate what is reachable, not just what is intended. Directory listing, exposed .git, backup files, and open management interfaces are the classic hits. Shadow or undocumented API surfaces make this worse; the shadow API asset inventory approach starts from observed hosts and routes rather than the deployment manifest.

A03:2025 — Software Supply Chain Failures#

New, and top-ranked in the community survey. The scope grew from "known vulnerable components" to the whole path that builds, distributes, and updates software. You are exposed when you do not track transitive dependencies, do not scan for vulnerabilities, run a CI/CD pipeline with weaker security than the systems it deploys, obtain packages from unofficial sources, or have no separation of duties between writing code and promoting it to production.

The named examples are worth knowing because they span the whole category: SolarWinds (2019, a compromised vendor build), Log4Shell and Struts RCE (component vulnerabilities), and the Shai-Hulud npm worm (2025), a self-propagating package that harvested npm tokens and republished malicious versions.

Test signal: generate an SBOM, follow transitive dependencies, and pin and verify (signed checksums, trusted registries). On the app side, this is where a poisoned JavaScript dependency lands; the site's prototype pollution work is the concretely-exploitable end of that. A plain version-to-CVE hit is illustrated by the CVE-2024-6387 anatomy.

A04:2025 — Cryptographic Failures#

Down two positions to #4. It covers the absence of cryptography where it is needed, cryptography that is too weak, and leakage of keys: passwords hashed with fast functions, reused or hard-coded keys, insecure modes, unseeded randomness, and deprecated primitives like MD5 and SHA1. The 2025 guidance also adds a forward-looking note: plan for post-quantum migration, with high-risk systems in scope by the end of the decade.

Test signal: classify the data first — you cannot protect what you have not labelled. Then require TLS 1.2+ with forward secrecy, authenticated encryption, an adaptive salted password hash (Argon2, scrypt, or PBKDF2-HMAC-SHA-512), and keys that never appear in source.

A05:2025 — Injection#

Injection falls to #5 but keeps the largest CVE count of any category. The definition is interpreter-agnostic: SQL, NoSQL, OS command, ORM, LDAP, and template/expression-language injection are the same bug with different interpreters. Cross-site scripting is included in this category, and LLM prompt injection is called out as a related but separately documented class (see the OWASP LLM Top 10).

Test signal: keep data separate from commands — parameterised queries, safe APIs, ORMs. Aim at every input surface: parameters, headers, cookies, JSON, XML, and the search parameters an ORM will happily turn into a predicate. The site covers two interpreters directly: NoSQL operator injection and the XSS lab guide.

A06:2025 — Insecure Design#

Down to #6. Insecure design is missing or ineffective control design: business-logic flaws, absent rate limits, and trust boundaries that were never modelled. A secure design can still contain implementation bugs; an insecure design cannot be fixed by an implementation patch alone, because the required control was never specified. Security-question recovery is weak identity evidence; NIST prohibits knowledge-based authentication when choosing passwords and defines account recovery separately. A booking flow with no domain rule against ordering the whole cinema at once is another example.

Test signal: threat-model the critical flows — authentication, access control, business logic, key money/state transitions — and write misuse cases alongside the use cases.

A07:2025 — Authentication Failures#

At #7. It is present when the system can be tricked into recognising an invalid user as legitimate: credential stuffing and password-spray attacks, permitted default or weak passwords, accounts created with breached credentials, knowledge-based recovery, missing or ineffective MFA, and session handling that exposes or fails to invalidate identifiers. The 2025 text also folds in validating the intended use of a credential — audience (aud), issuer (iss), and scope for tokens.

Test signal: check enumeration resistance (uniform messages), failed-attempt throttling that does not itself become a DoS, session regeneration on login, and server-side invalidation on logout. The desktop analogue of "the authenticator is a boundary you must own" runs through the site's Linux auth UI writing.

A08:2025 — Software or Data Integrity Failures#

Stays at #8, with a clarifying name change to "Software or Data". It is the lower-level sibling of A03: making assumptions about software updates, serialized data, or CI/CD artifacts without verifying their integrity. Deserialising untrusted data, consuming plugins or CDN scripts without integrity, and improperly controlled mass assignment (CWE-915) live here.

Test signal: sign and verify artifacts; avoid unsafe object deserialization of untrusted data, and if untrusted content must be parsed, use a data-only format with schema and size limits. Require integrity checks on anything fetched at runtime. On the JavaScript side, the untrusted-attribute-modification family overlaps with the prototype pollution material.

A09:2025 — Security Logging and Alerting Failures#

At #9, and — as OWASP itself notes — structurally under-represented in the data because it is hard to test. The rename to "Alerting" is the whole message: logging that no one acts on does not stop an incident. This category is present when auditable events (logins, failures, high-value transactions) are not logged, when log integrity is unprotected, when scans do not trigger alerts, when alert thresholds are missing, or when the logs themselves become a leak.

Test signal: log every security control's success and failure with enough actor context to act on, protect log integrity (append-only), and wire thresholds to a real response path. Two site posts carry this discipline end to end: security logging design and denied-request alert triage.

A10:2025 — Mishandling of Exceptional Conditions#

New for 2025, and it collects 24 CWEs that used to be dismissed as poor code quality. The failure has three shapes: the app does not prevent the unusual situation, does not detect it, or responds badly. That is how you get fail-open logic, unhandled exceptions, error messages with sensitive content (CWE-209), resource leaks, NULL dereferences, and multi-step transactions that corrupt state because they did not roll back entirely on the abnormal path.

Test signal: handle exceptions where they occur, add a global handler as a backstop, fail closed on partial transactions, and put rate limits on anything that can be hammered. The signal-handling race behind CVE-2024-6387 is an exceptional-condition failure at the OS level, and "always fail closed" is reinforced in the logging piece.

How to use this responsibly#

• It is awareness, not verification. The Top 10 names categories of risk; ASVS gives the testable requirements. Do not present a Top 10 pass as a security sign-off.
• The ranking is not your ranking. Positions come from contributed data plus a community survey. A category at #9 can be the one that loses your customer data.
• Read the CWE, not the label. Category names and positions change between editions (SSRF moved; "components" became "supply chain"). The stable join key is the CWE.
• "100% of applications" is the tested set. Statistics here describe the contributed sample, not all software everywhere.

Related Research & Internal References#

• API Access Control Test Plan - Object-level and function-level authorisation checks, mapped to OWASP API1/API3.
• IDOR/BOLA Test Plan - The reference-based access-control failure, end to end.
• BOLA Test Matrix Automation - Carrying the role × action × data matrix into automated scans.
• Security Logging Design - Audit schema, integrity, and fail-closed handling (A09/A10).
• Denied-Request Alert Triage - Turning deny streams into signals instead of noise (A09).
• Shadow API Asset Inventory - Enumerating what is actually exposed (A02).
• Prototype Pollution - A concretely exploitable JavaScript dependency attack (A03/A08).
• CVE-2024-6387 Anatomy - Version-to-CVE risk and signal-handling race (A03/A10).
• NoSQL Operator Injection and XSS Lab Guide - Two interpreters, one bug class (A05).
• Security Architecture of Authorisation and Authentication UIs on the Linux Desktop - Where the authentication boundary physically lives (A07).

Primary source: the OWASP Top 10:2025 release and its per-category pages. Where a verifiable requirement set is needed rather than an awareness list, use the OWASP Application Security Verification Standard (ASVS); for LLM applications, the OWASP LLM Top 10 handles prompt injection separately. This page is an editorial reading of that public material, cross-referenced to the site's own deep-dives; it is not an OWASP publication and it substitutes for neither the document nor a real assessment.