The OWASP Top 10 is the most widely referenced list of web application security risks. Customers ask about it in security questionnaires, PCI DSS refers to industry-standard lists like it, and almost every pentest proposal promises to cover it. The 2025 edition reshuffles the list and adds two new categories. This guide explains each risk in plain English, what a penetration tester does to find it, and what it means for your next test.
What changed in the 2025 edition
- Broken Access Control remains number one — still the most common serious flaw in real applications.
- Security Misconfiguration rises to number two, reflecting how much modern risk comes from configuration rather than code.
- Software Supply Chain Failures is new at number three, broadening the old "vulnerable and outdated components" category to the whole build and dependency chain.
- Mishandling of Exceptional Conditions is a new category at number ten, covering how applications behave when things go wrong.
- Server-Side Request Forgery is no longer a standalone category and is folded into the broader categories.
The OWASP Top 10:2025 explained
A01:2025 — Broken Access Control
Users can act outside their intended permissions: viewing another customer's records by changing an ID, calling admin functions as a normal user, or escalating privileges. What testers do: test every role against every function and object, especially across tenants. This is where manual testing earns its money — scanners can't know who should see what.
A02:2025 — Security Misconfiguration
Default accounts, verbose error messages, unnecessary features, permissive CORS, missing security headers, exposed cloud storage. What testers do: review server, framework and cloud configuration, look for debug endpoints and default content, and check hardening across environments.
A03:2025 — Software Supply Chain Failures
Risks from third-party libraries, build pipelines, package registries and deployment tooling — compromised dependencies, unpinned versions, or CI/CD systems an attacker can tamper with. What testers do: identify outdated and vulnerable components, review exposed build artefacts and, where in scope, assess CI/CD security.
A04:2025 — Cryptographic Failures
Sensitive data exposed through weak or missing encryption: outdated TLS, weak password hashing, hard-coded keys, predictable tokens. What testers do: check data in transit and at rest, token randomness, password storage and key management.
A05:2025 — Injection
Untrusted input interpreted as code or commands — SQL, NoSQL, OS command, LDAP, template injection and cross-site scripting. What testers do: combine automated payloads with manual analysis of how each input is processed, including second-order injection where data is stored and used later.
A06:2025 — Insecure Design
Flaws in the design itself rather than the implementation: workflows that can be skipped, missing rate limits on sensitive actions, trust placed in the client. What testers do: business-logic testing — abusing workflows, race conditions, pricing and approval steps.
A07:2025 — Authentication Failures
Weak login, session and recovery mechanisms: credential stuffing, weak password reset flows, session fixation, missing or bypassable MFA. What testers do: attack every authentication path, including password reset, "remember me", SSO and API tokens.
A08:2025 — Software or Data Integrity Failures
Code or data trusted without verification: insecure deserialization, unsigned updates, tamperable client-side data. What testers do: look for deserialization sinks, unsigned or unverified data flows and integrity checks that can be bypassed.
A09:2025 — Security Logging and Alerting Failures
Attacks happen but nobody notices: missing logs, logs without context, or no alerting on suspicious behaviour. What testers do: ask afterwards whether their activity was logged and alerted on — a valuable question to add to any pentest.
A10:2025 — Mishandling of Exceptional Conditions
Applications that fail unsafely when something unexpected happens: errors that leak information, fail-open logic, inconsistent state after partial failures. What testers do: deliberately trigger errors, timeouts and malformed inputs to see whether the application fails safely.
Is "OWASP Top 10 coverage" enough?
No. The Top 10 is an awareness document, not a testing standard. For actual test coverage, good firms work from the OWASP Web Security Testing Guide (WSTG) and, for higher-assurance applications, the Application Security Verification Standard (ASVS). If a vendor's methodology section only says "OWASP Top 10", ask what else they test. For APIs, also check coverage of the OWASP API Security Top 10.
Quick reference
| ID | Category | Best found by |
|---|---|---|
| A01 | Broken Access Control | Manual testing |
| A02 | Security Misconfiguration | Automated + manual review |
| A03 | Software Supply Chain Failures | Dependency analysis + review |
| A04 | Cryptographic Failures | Manual + tooling |
| A05 | Injection | Automated + manual |
| A06 | Insecure Design | Manual testing / threat modelling |
| A07 | Authentication Failures | Manual testing |
| A08 | Software or Data Integrity Failures | Manual + code review |
| A09 | Logging and Alerting Failures | Detection review / purple team |
| A10 | Mishandling of Exceptional Conditions | Manual testing |
Frequently asked questions
How often is the OWASP Top 10 updated?
Roughly every three to four years, based on contributed data and community surveys. The previous edition was 2021.
Does covering the OWASP Top 10 make an app secure?
No. It's an awareness list of the most common risk categories. Thorough testing follows the OWASP WSTG and, for high-assurance apps, ASVS.