The OWASP Top 10 (2025), explained
A plain-English guide to the OWASP Top 10 2025 web application risks, what changed from 2021, and what each category means for your application and team.
The OWASP Top 10 is the most widely used list of web application security risks. Customers, auditors and frameworks such as PCI DSS refer to it, so it’s worth knowing what it contains, and what it doesn’t. This guide covers the 2025 edition.
What the OWASP Top 10 is (and isn’t)
It is an awareness document: a ranked list of the broad risk categories most often found in real applications, based on data from thousands of tests plus a community survey.
It isn’t a testing standard or a checklist. An application can “pass” every category on paper and still have serious flaws in its business logic. A good penetration test uses the Top 10 as a starting point and follows a fuller methodology, such as the OWASP Web Security Testing Guide.
What changed from 2021
- Two new categories: Software Supply Chain Failures (A03), which expands the old “vulnerable and outdated components” category, and Mishandling of Exceptional Conditions (A10).
- Server-side request forgery (SSRF) is no longer its own category. It has been merged into Broken Access Control.
- Security Misconfiguration rose to second place, reflecting how much modern applications depend on configuration of cloud services, frameworks and containers.
The 2025 list
A01: Broken Access Control
Users can see or do things they shouldn’t, such as viewing another customer’s invoice by changing an ID in the URL, or calling an admin function as a normal user. It is still the most common serious issue we find in web and API tests. Fix: enforce authorisation on the server for every request, deny by default, and test each role against every other role’s data.
A02: Security Misconfiguration
Default settings, verbose error messages, unnecessary features, open cloud storage, missing security headers. Fix: a hardened, repeatable build process and regular configuration review.
A03: Software Supply Chain Failures
Risks from third-party libraries, build pipelines and update mechanisms: outdated components with known vulnerabilities, compromised packages, or tampered builds. Fix: keep an inventory (software bill of materials), monitor dependencies, pin and verify versions, and protect your CI/CD pipeline.
A04: Cryptographic Failures
Sensitive data sent or stored without proper encryption, weak algorithms, poor key management. Fix: TLS everywhere, strong modern algorithms, encryption at rest for sensitive data, and keys kept out of source code.
A05: Injection
Untrusted input interpreted as code or commands: SQL injection, command injection and cross-site scripting. (See our guide to cross-site scripting.) Fix: parameterised queries, safe APIs, context-aware output encoding, and input validation.
A06: Insecure Design
Flaws baked into the design rather than the code, such as a password reset that can be brute-forced or a workflow with no rate limits. Fix: threat modelling during design, and secure design patterns.
A07: Authentication Failures
Weak passwords allowed, credential stuffing not prevented, poor session handling, missing or bypassable multi-factor authentication. Fix: MFA, rate limiting, checks against breached passwords, and secure session management.
A08: Software or Data Integrity Failures
Trusting code or data without verifying it, for example insecure deserialisation, or auto-updates without signature checks. Fix: verify signatures and integrity, and don’t deserialise untrusted data.
A09: Security Logging and Alerting Failures
Attacks that go unnoticed because events aren’t logged or nobody is alerted. Fix: log authentication and access-control failures and high-value transactions, and make sure someone acts on alerts.
A10: Mishandling of Exceptional Conditions
Applications that behave unsafely when something unexpected happens, such as failing “open” on an error, leaking details in error messages, or leaving transactions half-completed. Fix: handle errors explicitly, fail safely, and test unusual and error paths, not just the happy path.
How to use the Top 10 in practice
- Developers: use it as a training baseline and a code review prompt.
- Product owners: ask suppliers and internal teams how each category is addressed.
- Buyers of a penetration test: expect the report to map findings to the Top 10, but also to cover business logic and anything specific to your application.
A web application or API penetration test checks your application against all ten categories, and against the logic flaws no list can anticipate.