13 December, 2025
If you build or look after web applications, you have probably bumped into the OWASP Top 10 at some point. It is a short, well known list of the most critical web application security risks, and many teams use it as a simple starting point for secure coding and testing.
Today the project page lists both the stable 2021 edition and a 2025 release candidate. The new version reshapes the categories to reflect how modern applications are built and attacked, with more focus on themes like software supply chain issues and error handling.
This blog explains how the Top 10 is built, what changed in the 2025 update, when to use it, when not to, and how to connect it with broader OWASP projects such as SAMM, ASVS and DSOMM to build a real application security program.
What is OWASP and what is the OWASP Top 10
OWASP, the Open Worldwide Application Security Project, is a non-profit foundation that exists to improve the security of software. It does this through community led open source projects, local chapters around the world, conferences, and freely available documentation that anyone can use in their organisation.
Within that ecosystem, the OWASP Top 10 is one specific project. It is a curated list of the ten most critical security risks for software systems, based on real world data and expert input. OWASP describes it as a “standard awareness document” that organisations should adopt as a first step toward more secure development, not as a full security framework. Over time it has become a de facto reference point for training, vendor tools and even compliance discussions, which is powerful, but also one of the reasons it is often misunderstood.
How the OWASP Top 10 is created and updated
The OWASP Top 10 has been around for more than twenty years. The first list appeared in 2003, with later updates in 2004, 2007, 2010, 2013, 2017 and 2021. OWASP now aims for a new edition roughly every three to four years, which is why the 2025 release candidate follows the 2021 list.
Each cycle starts with a large data call. Testing vendors, internal security teams and bug bounty platforms contribute real findings from their SAST, DAST, IAST and manual testing activities. For the 2025 edition, the project received data covering more than 2.8 million applications from a wide range of organisations, with vulnerabilities mapped to hundreds of CWEs.
Instead of just counting raw vulnerabilities, the team uses incidence rate, the percentage of applications that have at least one instance of a given weakness. They then group related CWEs into candidate categories, select the eight categories with the highest incidence, and reserve two slots for risks that emerge from the community survey.
The survey brings in the other half of the picture. For the 2025 cycle, 221 practitioners from different roles and industries shared which risks they see as most important, including issues that tools still struggle to detect, such as broken access control or insecure design.
Brian Glas, one of the project leads, commented that “It’s essential to understand why we construct the Top 10 in this manner. If it were purely data-driven, we would not have an accurate list, as it would only be looking into the past. The community survey is crucial in enabling people on the ground to share what they perceive as important risks that require visibility and attention, which may not be reflected in the data.”
Aram Hovsepyan, OWASP SAMM Core team member and Codific CEO, highlights that “absence of evidence is not evidence of absence”, which is why careful statistical work and normalisation are needed.
Glas also points out that the list is only updated every three to four years on purpose, to give the industry a stable baseline to work with between releases rather than a constantly shifting target.
OWASP Top 10 2025 categories explained
The current OWASP Top 10 2025 release candidate focuses on ten risk areas that show up again and again in real applications. Here is a short you can view of each one.
A01:2025 Broken Access Control
When users can see or do things they are not meant to. For example, horizontal or vertical privilege escalation, IDORs, or bypassed authorization checks.
A02:2025 Security Misconfiguration
Everything was built correctly, but wired up wrong. Default passwords, open admin consoles, missing security headers, or overly permissive cloud storage all live here.
A03:2025 Software Supply Chain Failures
Problems in the way you build, update, or deliver software. This includes vulnerable or malicious dependencies, compromised build systems, and tampered artifacts.
A04:2025 Cryptographic Failures
Weak or broken protection for data in transit or at rest, such as outdated algorithms, bad key management, or missing encryption where it is needed.
A05:2025 Injection
Untrusted data is sent to an interpreter or parser and treated as code, for example SQL, OS command, LDAP, or template injection.
A06:2025 Insecure Design
Architectural and design level flaws, often caused by missing threat modelling, unsafe patterns, or trying to bolt security on at the end.
A07:2025 Authentication Failures
Login, session and identity handling bugs, such as weak credential rules, broken session management, or poor multi factor enforcement.
A08:2025 Software or Data Integrity Failures
Code or data can be changed without proper checks, for example unsafe update mechanisms, untrusted plugins, or unsigned packages.
A09:2025 Logging and Alerting Failures
Important security events are not logged, not stored safely, or never trigger alerts, so attacks go unnoticed until real damage is done.
A10:2025 Mishandling of Exceptional Conditions
When things go wrong at runtime, error handling and recovery are not safe. Unhandled exceptions, fail open behaviour, or verbose error messages can all become attack paths.
OWASP Top 10 2025 release candidate – what changed from 2021
The 2025 release candidate keeps most of the 2021 topics, but reshapes and reorders them. There are two new categories, one consolidation, and a stronger focus on root causes like supply chain and error handling.
Here is a comparison of the category changes from 2021 to 2025:
The key changes are:
- Two new categories
- Software Supply Chain Failures (A03) grows out of 2021’s Vulnerable and Outdated Components and now covers the full lifecycle, from third party packages to build and deployment systems.
- Mishandling of Exceptional Conditions (A10) is completely new, bringing together error handling, fail open logic and resilience problems that were previously scattered across quality related CWEs.
- One consolidation
- SSRF (A10:2021) is no longer a separate item. It is now treated as a specific form of Broken Access Control, and its main CWE (CWE 918) is mapped into A01:2025
- Renamed and reordered categories
- Security Misconfiguration moves up from A05:2021 to A02:2025, reflecting how often misconfigurations are found across modern stacks.
- Identification and Authentication Failures is shortened to Authentication Failures, but keeps the same focus on broken login and session handling.
- Security Logging and Monitoring Failures becomes Logging and Alerting Failures, highlighting the need not just to collect logs, but to trigger and act on alerts.
For readers, the practical takeaway is that the 2025 update does not throw away the 2021 work. Instead, it sharpens it around two themes that have become impossible to ignore in recent years: software supply chain risk and how systems behave when something goes wrong.
Insights from Brian and Aram:
Brian Glas: Mishandling of Exceptional Conditions is a category that has been just outside the Top 10 for several years. In this iteration, there was enough data and support from the community survey to push it over the line and into the Top 10. This is part of the goal of the Top 10 to raise the baseline on each iteration to help improve software security globally.
Aram Hovsepyan: Based on more than 50 in-depth security assessments we conducted with Brian across Fortune 500 companies and beyond, we have rarely seen teams address this risk effectively. It is an area that demands close collaboration between development, operations, and incident management teams, which are often highly siloed, especially in large organizations.
Why is the OWASP Top 10 important?
The OWASP Top 10 gives you a shared language for the most critical web application risks.
For organisations, it is a simple way to focus limited security effort. Instead of trying to fix every possible issue at once, you can map your applications, tools and controls against ten categories that cover the majority of serious web flaws seen in the wild. This makes it easier to prioritise investment, training and testing where they will have the most impact.
For developers, the Top 10 is a practical learning roadmap. It highlights the vulnerabilities that attackers actually exploit, then links to concrete guidance and examples. Teams that integrate the Top 10 into secure coding guidelines, code review checklists and onboarding can raise their security baseline. They can do this without adding heavy processes on day one.
Finally, many regulators, industry standards and customers now reference the OWASP Top 10. Knowing it well helps you respond to security questionnaires, align with external expectations and demonstrate that you are taking common web risks seriously.
When you should and should not use the OWASP Top 10
When you should use the OWASP Top 10
- As an awareness and training tool
OWASP explicitly describes the Top 10 as a standard awareness document. It is ideal for onboarding developers, product owners and testers, and for structuring internal workshops or secure coding training. Treat each category as a theme to explore with examples from your own applications. - As a starting point for an AppSec program
If your organisation is early in its application security journey, the Top 10 is a good first map. You can review how your current controls, tests and tools line up against the ten risk areas, then use that to decide where to focus next, for example access control, misconfigurations or supply chain. - As a shared language with stakeholders
The Top 10 gives security and engineering teams a simple way to explain issues to management, customers and vendors. Talking about “Broken Access Control” or “Software Supply Chain Failures” is often clearer than throwing around individual CVEs or tool findings.
When you should not use the OWASP Top 10
- Not as a complete security standard or checklist
The Top 10 is not a full framework for building or assessing secure software. It does not cover all relevant risks, and it does not replace threat modelling, architecture reviews, secure design practices or broader risk management. - Not as a strict compliance requirement
Some procurement teams and customers write “must comply with OWASP Top 10” into contracts. That sounds precise but is hard to verify and easy to misunderstand. It is better to refer to more detailed standards, such as OWASP ASVS for requirements or OWASP SAMM for program maturity, and keep the Top 10 as context. - Not as your only metric for progress
Being “Top 10 compliant” does not mean your applications are secure. Mature organisations define their own risk picture and internal priorities, and use the OWASP Top 10 as one of several inputs, not the final goal.
Brain Glas mentioned a good point on this if you’re having doubts; “It’s basically impossible to create a Top 10 that exactly matches everyone’s experiences and perceptions. It’s basically a model and a baseline. The goal is to highlight risks that are important to address to raise the minimum bar for secure development globally. Every organization has its own “Top 10” (or Top 3) that they identify, focus on, and reduce as much as possible. You should update your own Top 10 more frequently. The OWASP Top 10 is updated every 3-4 years to provide stability and allow the industry time to focus.”
When will the new OWASP Top 10 come out?
OWASP has published the OWASP Top 10 2025 as a release candidate. This means the content is largely stable. The project team is still collecting feedback from the community before they finalise it as the official 2025 edition.
There is no fixed public date for the final release. In previous cycles, the gap between a release candidate and the final version has usually been a few months. For practical purposes, you can already start using the 2025 RC to guide discussions and planning. Just keep an eye on the OWASP Top 10 project page for the final publication and any small adjustments.
Beyond the OWASP Top 10 – OWASP SAMM, ASVS, and DSOMM
The OWASP Top 10 is just the tip of the iceberg. It is an awareness document, not a complete blueprint for everything your organisation should do about application security. If you stop at the Top 10, you only see the visible part of the risk, not the underlying practices that keep those issues from coming back.
That is where OWASP SAMM, ASVS and DSOMM come in. Together, they act as guides for what a mature security program should look like. They cover everything from governance and design to technical requirements and DevSecOps pipelines. They go far beyond ten high level categories and describe how to build and verify secure software in a repeatable way.
Aram Hovsepyan: “OWASP SAMM, OWASP ASVS, OWASP DSOMM are my top 3 projects you should be looking at. These projects provide you with the necessary tools to actually improve your security posture so that the Top 10 risks never happen again!”
Brian Glas: The scope of SAMM is much broader than the Top 10. That’s why the name is “Software Assurance”. SAMM covers the full scope, from Governance (strategy, policy, training) through the SDL to Operations (incident response, data management, lifecycle management).
This is exactly the problem SAMMY is built to solve. Instead of wrestling with spreadsheets and static checklists, you can use SAMMY to:
- Run SAMM, ASVS or DSOMM based assessments in a structured way
- See where you stand today and which improvements matter most
- Track changes over time so you can show that Top 10 risks are being driven down, not just patched once
In other words, the OWASP Top 10 tells you what to worry about.
The OWASP frameworks explain what “good” looks like.
SAMMY then gives you an easy way to organise, track and refine that journey in your own organisation.
