OWASP Top 10 2025: the 10 categories and what changed since 2021

The OWASP Top 10 is the most widely cited reference in web application security. The 2025 edition, the eighth installment of the list, is the official version published by OWASP and brings meaningful changes compared with 2021: two new categories, one consolidation and several shifts in ranking. Below: each category, what changed, and how to use the list without treating it as a complete checklist.

What the OWASP Top 10 is

OWASP itself defines the Top 10 as an awareness document: a broad consensus on the most critical risks to web applications. Each category groups several weaknesses from the CWE catalog, maintained by MITRE, under a common name. In the 2025 edition, the ten categories contain 248 CWEs.

The methodology is "data-informed, but not blindly data-driven". Eight categories come from testing data contributed by companies and researchers, which according to OWASP covers more than 2.8 million applications. The other two come from a survey of practitioners, to capture risks that tools still cannot measure at scale.

The ten categories of the 2025 edition

A01 – Broken Access Control. Users can act outside their intended permissions: view another customer's data, reach administrative functions, change records that are not theirs. It remains in first place and now includes SSRF.
A02 – Security Misconfiguration. Insecure defaults, unnecessary services and accounts, verbose error messages, missing headers, misconfigured cloud storage. It grows as more of an application's behavior depends on configuration.
A03 – Software Supply Chain Failures. Compromises or weaknesses in the process of building, distributing or updating software: vulnerable or unmaintained dependencies, malicious changes to third-party components, uncontrolled build pipelines.
A04 – Cryptographic Failures. Missing encryption where it is needed, weak algorithms, poorly managed keys, or sensitive data transmitted and stored in clear text.
A05 – Injection. Untrusted data interpreted as a command or query. It ranges from Cross-site Scripting, frequent and usually lower impact, to SQL Injection, less frequent and high impact.
A06 – Insecure Design. Flaws born in the architecture and business logic, not in the implementation: a flow with no limit on attempts, or a business rule that can be bypassed.
A07 – Authentication Failures. Weak passwords accepted, no protection against automated credential attacks, poorly managed sessions, fragile account recovery.
A08 – Software or Data Integrity Failures. The application trusts code, updates or data without verifying their integrity, such as insecure deserialization or unsigned automatic updates.
A09 – Security Logging and Alerting Failures. Relevant events are not logged, or are logged without anyone being alerted. Logs without alerts do little to detect an incident.
A10 – Mishandling of Exceptional Conditions. The application fails to prevent, detect or properly respond to abnormal situations: errors that leak information, unhandled exceptions, logic that "fails open" and grants access when something goes wrong.

What changed since 2021

Two new categories. A03, Software Supply Chain Failures, expands the former A06:2021 (Vulnerable and Outdated Components) to cover the whole chain of dependencies, build and distribution. According to OWASP, it was the top-voted risk in the community survey and has the highest average exploit and impact scores among the CVEs analyzed. A10, Mishandling of Exceptional Conditions, is brand new and gathers error-handling and logic weaknesses previously scattered under "code quality".
One consolidation. Server-Side Request Forgery, which was A10:2021, has been rolled into A01, Broken Access Control.
Moving up. Security Misconfiguration rose from 5th to 2nd place.
Moving down. Cryptographic Failures dropped from 2nd to 4th, Injection from 3rd to 5th and Insecure Design from 4th to 6th. For Insecure Design, OWASP attributes part of the drop to industry progress in threat modeling.
Same place, new name. A07 dropped "Identification" from its name (it was Identification and Authentication Failures). A09 replaced "Monitoring" with "Alerting", to stress that logging without alerting is not enough. A08 kept its position.

Dropping in the ranking does not mean the risk is solved: according to OWASP, injection is still the category with the most associated CVEs.

How to use the Top 10 (and how not to)

OWASP is explicit: the Top 10 is a starting point, not a complete list. It discourages any claim of "full OWASP Top 10 coverage", including by tool vendors, because categories such as Insecure Design cannot be detected in an automated way.

Awareness and training. This is where the Top 10 shines: giving developers, product and management a shared vocabulary for the most relevant risks.
Requirements and verification. For a verifiable standard, OWASP's own recommendation is the ASVS (Application Security Verification Standard), currently at version 5.0.0, with requirements organized by level that can go into user stories, acceptance criteria and vendor contracts.
Testing. The WSTG (Web Security Testing Guide) describes how to test each area of a web application and is the reference methodology for application penetration testing.

In one sentence. Use the Top 10 to know where to look first, the ASVS to define what to require and the WSTG to define how to test.

How to test an application against these risks

No single technique covers all ten categories:

SAST (static analysis). Examines source code for insecure patterns, such as input concatenated into queries or weak cryptography. It runs early in the pipeline, but produces false positives and does not understand business rules.
SCA and component inventory. Identifies the libraries and versions in use, including transitive dependencies. It is the foundation for addressing A03, together with controls over the build pipeline.
DAST (dynamic analysis). Tests the running application from the outside in. Good for injection, configuration and headers; weak for authorization between users and business logic.
Manual code review. Finds what tools miss: a missing permission check on an endpoint, exception handling that fails open, an insecure design decision.
Application penetration testing. Testers exploit the application as an attacker would, following a methodology such as the WSTG, with a focus on what automated tools detect poorly: access control (A01), authentication (A07), business logic and exceptional conditions (A10). In gray box mode, with credentials for different roles, it is the most direct way to prove whether one user can reach another user's data.

Some risks can only be assessed by talking to people and looking at the process. OWASP itself notes that verifying whether logging and alerting actually work (A09) requires interviews and evidence of incident response, and that insecure design (A06) is beyond the reach of most forms of testing. That is why threat modeling during design, and feeding application logs into security monitoring, complete the picture.

Frequently asked questions

Is the 2025 edition of the OWASP Top 10 the official version?

Yes. The official OWASP site presents the Top 10:2025 as the released edition, with the ten categories A01 to A10 described in this article. The 2021 edition remains available for reference and comparison.

Does meeting the OWASP Top 10 mean my application is secure?

No. The Top 10 covers the most critical risks, not all of them, and OWASP describes it as the bare minimum. For a complete, verifiable set of requirements, use the ASVS; for the testing methodology, the WSTG.

Can an automated tool cover the whole Top 10?

No. OWASP itself states that tools cannot comprehensively detect, test or protect against every category, Insecure Design in particular. Tools are essential for scale; manual review and penetration testing cover what they cannot reach.

Sources consulted on 10 October 2026: OWASP, OWASP Top 10:2025 (introduction, category pages, "Establishing a Modern Application Security Program" and "Next Steps"); OWASP, OWASP Top 10:2021; OWASP Application Security Verification Standard (ASVS) 5.0.0; OWASP Web Security Testing Guide (WSTG); MITRE, Common Weakness Enumeration (CWE). This article is educational; refer to OWASP's official text for the full description of each category and its mapped CWEs.