How the List Is Assembled and What It Measures
OWASP assembles the Top 10 from contributor data: security vendors, bug bounty programs, pentest firms, and application security teams submit counts of how frequently each vulnerability class appears across tested applications. The list reflects what was actually found in production code over the previous collection period, not just theoretical risk.
There is also a community-nominated category for emerging risks that may not yet be statistically dominant but represent a significant directional shift in where attacker activity is concentrating. In 2021, that slot went to Server-Side Request Forgery. The 2025 revision's nominated entry reflects the changed landscape since then.
This structure matters when reading the update because some changes indicate a genuine increase in prevalence, while others indicate where the community expects attacker focus to shift in the coming years. Reading both together gives a clearer picture than treating the list as a static ranking.
What the 2025 Revision Reflects About Supply Chain Risk
The 2021 list categorized Vulnerable and Outdated Components as a distinct entry, addressing the straightforward case: a library with a known CVE that has not been patched. The 2025 revision expands this framing substantially.
Supply chain risk now encompasses build system integrity, container image provenance, CI/CD pipeline exposure, and package manager resolution behavior in multi-registry configurations. The category name is less important than what it now covers. Library-level CVE scanning was the starting point. The 2025 update reflects that attackers have moved further up the supply chain, targeting build infrastructure rather than just packaged output.
For teams using private artifact registries, the practical implication is that registry configuration is now part of a security posture assessment. How package managers resolve name conflicts between internal and external registries, whether artifact checksums are pinned in lockfiles, whether CI jobs pull from verified sources: these are concrete findings in a supply chain assessment that did not clearly belong in any 2021 category.
Broken Access Control and Why It Stays at the Top
Broken Access Control was the top-ranked category in 2021, and the 2025 data does not dislodge it. The persistence reflects something structural: access control failures are hard to detect comprehensively with automated tooling because reliable detection requires understanding the intended authorization model, which is application-specific.
The common patterns are consistent across codebases. An API endpoint checks authentication but not whether the authenticated user has rights to the specific resource, producing an Insecure Direct Object Reference. An admin endpoint is guarded at the API gateway but reachable directly if the caller knows the path. A service-to-service call bypasses the authorization layer because it originates from "internal" infrastructure. These are not novel issues. They persist because scanners cannot reliably detect them without semantic understanding of the authorization model the application is supposed to enforce.
The 2025 revision tightens the framing around what counts as broken access control in microservice and API-heavy architectures, where the authorization boundary is distributed across multiple layers and each layer can have independent gaps.
Cryptographic Failures and Where They Hide
Cryptographic Failures has remained near the top of the list because the common failure mode is subtle. Applications do not typically fail to encrypt sensitive data entirely. They encrypt it using deprecated or misconfigured algorithms, or they use encryption in ways that do not provide the expected protection.
In practice this shows up as passwords hashed with MD5 or SHA-1 without a salt, JWT tokens signed with HS256 using a weak or broadly shared secret, TLS configuration still accepting version 1.0 or 1.1 on endpoints handling sensitive data, and AES in ECB mode applied to structured data where the block pattern leaks information. Each of these passes a naive "is encryption used" check. None provides the protection the developer assumed when writing the code.
The 2025 revision adds coverage of cryptographic API misuse patterns common in newer application code, including weak random number generation in token construction and predictable nonces in authenticated encryption schemes. These are code-level findings, not architecture findings, and they are detectable with static analysis on the relevant code paths.
The Community-Nominated Entry: AI and LLM Attack Surfaces
The 2025 community-nominated category addresses attack surfaces that have grown substantially since the 2021 list was assembled. Applications that send user input to language model APIs and act on the output introduce a class of injection risk that was not meaningfully present in most codebases four years ago.
Prompt injection, where user-controlled input causes a language model to produce output that bypasses intended controls, is the most discussed variant. But the broader risk is in how LLM output flows to downstream systems. An LLM response rendered without sanitization can introduce XSS. An LLM response used to construct a query without parameterization is an injection surface. The intermediate actor is different from SQL injection, but the underlying condition, user-controlled data flowing to a trusted system without validation at the boundary, is the same.
This does not appear on the Top 10 proper because prevalence data is still accumulating. It is in the nominated category because the trajectory is clear. Applications that interact with LLM APIs should treat LLM output the same way they treat user input from an untrusted source: validate, sanitize, and do not pass it directly to another interpreter without appropriate controls.
What the List Does Not Tell You
The OWASP Top 10 is not a comprehensive security assessment, and using it as one is a documented failure mode. It tells you which vulnerability classes are statistically common across a large sample of applications; it does not tell you which of those classes you have, at which severity level, in your specific codebase.
It also does not rank within-category risk. A stored XSS in an admin panel accessed only by internal users has different exploitability than a stored XSS in a customer-facing message thread. The category is the same. The priority is not. The list provides category coverage guidance, not a prioritized fix list for your application.
The practical use of the 2025 revision is as a starting-point check for scanner coverage: are you testing for the categories that are now in scope? For supply chain, that means more than CVE scanning. For access control, it means tracing authorization to the data layer, not just checking for authentication at the API layer. For cryptographic failures, it means checking cipher configuration in code, not just confirming that TLS is present. The update recalibrates where real-world risk is concentrated based on the most recent incident data. That is useful context, and it is also not a substitute for an actual assessment of your specific application.
