The OWASP Top 10 is a list of ten categories of security risk for web applications (programs people use through a browser), published by OWASP, a community focused on application security. The official page calls it an awareness document for developers. The most current edition is OWASP Top 10:2025. This article summarizes all ten categories, what changed from the 2021 edition, and what executives and development teams should do next.
What the OWASP Top 10 is, and is not
The OWASP Top 10 lists common risk categories. It is not a checklist that makes an application safe once completed. The official OWASP page says the Top 10 is only a minimum baseline, and to set security requirements for an application it points to ASVS (Application Security Verification Standard, an OWASP standard of requirements that can be verified and tested).
The 2025 edition draws on data from more than 2.8 million applications. The team analyzed 589 CWEs (Common Weakness Enumeration, a standard catalog of software weakness types), and the ten categories cover 248 of them. Two of the ten were chosen from a community survey to cover risks that testing data may under-represent: A03, on the software supply chain (the code, tools and components from other parties that our software depends on), and A09, on logging and alerting.
All ten categories in the 2025 edition
The list as shown on the official OWASP page is:
- A01:2025 Broken Access Control: users can act beyond their permissions, for example viewing or changing data they should not touch
- A02:2025 Security Misconfiguration: systems, applications or services are set up insecurely
- A03:2025 Software Supply Chain Failures: breakdowns in building, distributing or updating software, for example a third-party component altered to be malicious
- A04:2025 Cryptographic Failures: weak or missing encryption can expose sensitive data
- A05:2025 Injection: user-supplied data is interpreted by the system as a command or query
- A06:2025 Insecure Design: security controls are missing from the design stage
- A07:2025 Authentication Failures: identity checks and session handling (the period in which the system remembers the user is logged in) can be bypassed or broken
- A08:2025 Software or Data Integrity Failures: code or data is trusted without checking whether it was tampered with
- A09:2025 Security Logging and Alerting Failures: security events are not recorded, or not raised in time to respond
- A10:2025 Mishandling of Exceptional Conditions: errors and abnormal situations are handled improperly
What changed from the 2021 edition
According to the OWASP introduction page, the main changes are:
- SSRF folded into A01: SSRF (Server-Side Request Forgery, tricking a server into calling an address the attacker chooses) now sits in Broken Access Control, which stays at number 1
- A03 widened: Software Supply Chain Failures expands A06:2021 Vulnerable and Outdated Components to cover attacks through dependencies (libraries an app uses), build systems and distribution channels
- A10 is new: Mishandling of Exceptional Conditions has 24 CWEs covering improper error handling, logical errors and failing open
- Rank changes: A02 Security Misconfiguration rose from 5 to 2, while A04, A05 and A06 each fell two places, from 2, 3 and 4 to 4, 5 and 6
- Renames: A07 became Authentication Failures and A09 became Security Logging and Alerting Failures, to stress alerting
Some scanning tools still reference the 2021 edition. For example, DynaSec's free web scanner at webscan.dynasec.pro maps its results to OWASP Top 10 (2021). Most categories can be compared, but those whose name or scope changed, such as SSRF, need to be mapped by hand, and whichever report you read, check first which edition it refers to.
Three categories worth understanding in more depth
A01 Broken Access Control remains number 1. The official page reports that 100% of tested applications had some form of this flaw, and that it had the most occurrences in the contributed data. OWASP recommends, for example, denying access by default except for public resources, enforcing checks in trusted server-side code that attackers cannot alter, tying access to record ownership, and including access control checks in automated tests.
A03 Software Supply Chain Failures means breakdowns in building, distributing or updating software. They often stem from vulnerabilities or malicious changes in third-party code, tools or dependencies. The official page says this category ranked first in the community survey. OWASP recommends generating and maintaining an SBOM (software bill of materials, a list of every component inside the software), removing unused dependencies, obtaining components from trusted sources, and hardening code repositories and the CI/CD pipeline (the automated steps that build and release software). Read more in SBOM and Software Supply Chain Security and DevSecOps: SAST, DAST and SCA.
A10 Mishandling of Exceptional Conditions occurs when software fails to prevent, detect or respond properly to unusual situations. The official page gives three examples. The first is an application that does not release resources after an error until the service stops. The second is an overly detailed error message that reveals system internals. The third is a multi-step transaction that is interrupted and not fully rolled back, which may let funds be drained.
Viewing it as an executive and as a development team
Executives can ask their teams these four questions. They are our own suggestion, based on OWASP's guidance for building an application security program:
- Which applications and APIs matter most to the business, and is the inventory complete?
- Which security standard must the development team follow, such as ASVS, and who verifies it?
- Has the team received security training suited to its roles?
- Are there metrics to track, such as vulnerabilities found and fixed, and how many applications have been tested?
A development team can apply the prevention points OWASP lists for each category right away, for example:
- Deny access by default and enforce permission checks in server-side code (A01)
- Generate an SBOM and remove unused dependencies (A03)
- Handle errors where they occur, add a global exception handler, and fully roll back incomplete transactions (A10)
- Log denied access and alert administrators on repeated failures (A01, A09)
A WAF (web application firewall, a firewall that filters web requests) can filter some harmful requests, but it does not replace fixing the code, because the flaw in the application remains. For the differences between these devices, see NGFW vs UTM vs WAF: What Each One Protects. For the risks of APIs specifically, read API Security and the OWASP API Top 10 Explained.
Common mistakes
- Using the Top 10 as a complete acceptance checklist: OWASP says it is only a minimum baseline
- Citing the 2021 edition in policy or contracts without checking for the new one: the latest is 2025 and some categories changed
- Fixing each scanned flaw without fixing the development process: the same kinds of flaws return
- Assuming a WAF or firewall can replace code fixes: the flaw in the application remains
- Ignoring dependencies and build systems because the team's own code is fine: A03 comes from parts the team did not write
Start today
- Check whether your policies, contracts and scanning tools cite the 2021 or the 2025 edition
- Inventory applications and APIs, ranked by business importance
- Review access control (A01) in the most important application first
- Generate an SBOM and a dependency list for those applications
- Set a metric executives can read, such as vulnerabilities found and fixed
To see where your organization stands, try the self-assessment.
References and further reading
- OWASP Top 10:2025: the 2025 home page with the list of ten categories
- Introduction (2025): what changed from 2021 and where the data came from
- A01:2025 Broken Access Control: description and prevention for A01
- A03:2025 Software Supply Chain Failures: description and prevention for A03
- A10:2025 Mishandling of Exceptional Conditions: description and examples for A10
- Establishing a Modern Application Security Program: building an application security program, and the role of ASVS
- OWASP Top 10:2021: the previous edition, for comparison with 2025
- OWASP Application Security Verification Standard (ASVS): the verifiable requirements standard
- OWASP Cheat Sheet Series: developer guidance by topic