The OWASP Top Ten vulnerabilities is a regularly updated, community-driven list of the ten most critical web application security risks, maintained by the Open Worldwide Application Security Project as the de facto baseline for what every application team should defend against. It is not a compliance standard or an exhaustive catalog. It is a prioritized starting point, and its value is precisely that focus: if you address these ten categories well, you have closed off most of the ways real applications actually get breached.
The list is revised every few years as attack patterns shift. The current edition is the OWASP Top 10:2025, and it reflects a notable change in emphasis, from individual coding bugs toward systemic risks in configuration, dependencies, and operations. If your mental model is still the 2021 list, a few things have moved, and one important new category has appeared.
The 2025 list at a glance
Here is the current ordering, from the official OWASP Top 10:2025:
- A01 Broken Access Control — users acting outside their intended permissions. Still number one, and now includes server-side request forgery, which was its own category in 2021.
- A02 Security Misconfiguration — insecure defaults, verbose errors, and unhardened settings. Moved up from fifth in 2021, reflecting how much risk now lives in configuration.
- A03 Software Supply Chain Failures — the expanded successor to 2021's "Vulnerable and Outdated Components," now covering the integrity of acquisition, build, and distribution, not just known-vulnerable libraries.
- A04 Cryptographic Failures — weak or misused cryptography exposing sensitive data.
- A05 Injection — untrusted input interpreted as commands, including SQL and command injection.
- A06 Insecure Design — flaws baked into the architecture rather than the implementation.
- A07 Authentication Failures — weak identity verification and session management.
- A08 Software or Data Integrity Failures — trusting code or data whose integrity was never verified.
- A09 Security Logging and Alerting Failures — insufficient visibility to detect and respond to attacks.
- A10 Mishandling of Exceptional Conditions — a new category covering unsafe handling of errors and edge cases.
Two entries deserve special attention because they signal where the industry's thinking has gone.
Broken access control stays on top
Access control failures remain the most impactful category, and it is worth understanding why they are so persistent. The classic example is object-level authorization: a user requests /api/orders/1002 and, by changing the number, reads someone else's order because the server checked that the user was logged in but never checked that this order belonged to them.
These flaws are common because they are logical, not syntactic. No scanner can infer your authorization rules; it has to be told. Defense means enforcing access decisions server-side on every request, denying by default, and testing authorization with multiple accounts at the same privilege level to catch the case where one user can reach another's data.
Software supply chain failures move up
The most significant structural change in 2025 is the promotion and expansion of supply-chain risk to the third position. Where 2021 focused narrowly on components with known CVEs, the 2025 category acknowledges that the danger extends to the integrity of the whole pipeline, how artifacts are acquired, built, and distributed, not just whether a library has a published vulnerability.
This reflects a wave of real-world attacks: poisoned packages, compromised build systems, and hijacked maintainer accounts. Defending against it means inventorying every dependency including transitive ones, verifying provenance, pinning versions, and monitoring for both known vulnerabilities and malicious behavior. An SCA tool such as Safeguard can produce that dependency inventory and flag vulnerable transitive components before they ship, which is exactly the kind of visibility this category demands. If you want a deeper treatment of the topic, see our malicious code detection guide.
How to actually use the list
The mistake teams make is treating the Top Ten as a checklist to tick once. It works better as an organizing framework for your entire program. Map each category to a control and a test:
Access control and authentication map to authorization testing and secure session management. Injection and cryptographic failures map to static analysis and input-handling review. Supply chain and integrity failures map to composition analysis and artifact signing. Misconfiguration and logging failures map to infrastructure hardening and detection engineering. The new exceptional-conditions category maps to reviewing how your code handles errors and edge cases without leaking information or failing open.
Wire those tests into your pipeline so coverage is continuous rather than annual. Dynamic testing, such as our DAST product, exercises many of these categories against a running application automatically, catching regressions the day they appear.
Where the list stops
The Top Ten is deliberately a floor, not a ceiling. It covers the categories that affect the most applications, but your product may have risks it does not address, business-logic abuse, tenant isolation, or domain-specific fraud. Treat the Top Ten as the baseline everyone must clear, then extend with threat modeling specific to what you build. Clearing the baseline is a real achievement; assuming it is the whole job is how teams get surprised.
FAQ
What is the current OWASP Top Ten edition?
The current edition is the OWASP Top 10:2025, which replaced the 2021 list. It reorders several categories, expands vulnerable components into a broader "Software Supply Chain Failures" category, and adds a new "Mishandling of Exceptional Conditions" entry.
What changed between the 2021 and 2025 lists?
Security Misconfiguration moved up to second, Software Supply Chain Failures rose to third as an expanded version of the old components category, server-side request forgery was folded into Broken Access Control, and a new category for mishandling exceptional conditions was added at tenth.
Is the OWASP Top Ten a compliance standard?
No. It is a community-driven awareness document that ranks the most critical web application risks. Some standards and questionnaires reference it, but it is not itself an audited compliance framework. Treat it as a prioritized baseline rather than a certification checklist.
Does covering the Top Ten mean my application is secure?
It means you have addressed the most common categories of risk, which is a strong baseline, but not that you are fully secure. The list is deliberately a floor. Business-logic flaws and domain-specific risks require threat modeling beyond what the Top Ten covers.