The OWASP Top 10 2025 is the eighth edition of the industry’s best-known list of web application security risks, and the reference point behind most web application penetration testing. It is a standard awareness document, not a checklist you certify against, but it frames what a real test looks for and what a customer means when their security questionnaire says “tested against the OWASP Top 10.” This guide covers all ten 2025 categories in plain terms, what changed from the 2021 edition, and, for each one, the kind of finding a tester actually turns up and how we confirm it.
What is the OWASP Top 10 2025, and what changed
OWASP describes the list as “a standard awareness document for developers and web application security” that “represents a broad consensus about the most critical security risks to web applications.” It is data-informed but not blindly data-driven: OWASP ranked twelve candidate categories on data contributed for over 2.8 million applications, took eight of the final ten from that ranking, and let a community survey of practitioners promote the other two, because the data can only show what the industry already knows how to test at scale. This edition analyzed 589 CWEs, up from almost 400 in 2021.
Three things changed for 2025: two new categories and one consolidation.
| 2025 | Rank change from 2021 | Note |
|---|---|---|
| A01 Broken Access Control | Held #1 | SSRF folded in |
| A02 Security Misconfiguration | Up from #5 | Configuration-driven software keeps rising |
| A03 Software Supply Chain Failures | Expanded from “Vulnerable and Outdated Components” | Top-voted survey concern |
| A04 Cryptographic Failures | Down from #2 | |
| A05 Injection | Down from #3 | XSS lives here |
| A06 Insecure Design | Down from #4 | |
| A07 Authentication Failures | Held #7 | Renamed from “Identification and Authentication Failures” |
| A08 Software or Data Integrity Failures | Held #8 | |
| A09 Security Logging and Alerting Failures | Held #9 | Renamed to stress alerting, not just logging |
| A10 Mishandling of Exceptional Conditions | New for 2025 | Error handling, failing open, logic errors |
If you work to “OWASP Top 10 2025,” those are the ten. Note this is the web application list; mobile, APIs, and LLMs have their own, linked at the end.
The ten, with a real finding for each
For every category below, the example finding is the kind of thing a manual test turns up in a real build, and the tester note is how we confirm it.
A01: Broken Access Control. Still number one; OWASP reports that every application tested had some form of it. This is one user reaching another user’s data or actions: changing an ID in a request to read someone else’s invoice (an insecure direct object reference), calling an admin-only API as a standard user, or tampering with a JWT to elevate privileges. SSRF now sits here too. Tester note: we test with an account in each role, and as an anonymous user, and try to cross every boundary the application defines. This is the single most common serious finding in a web test, and no scanner reliably finds it because it requires understanding what each role is allowed to do.
A02: Security Misconfiguration. Up to #2. A system set up insecurely: missing hardening, default accounts left enabled, verbose error pages that leak stack traces, an open cloud storage bucket, missing security headers. Tester note: we check the whole stack, from the framework’s debug settings to the cloud service permissions, because misconfiguration is now where much of an application’s behavior lives.
A03: Software Supply Chain Failures. New name, bigger scope, top-voted concern. This expands the old “vulnerable components” entry to cover the whole dependency, build, and distribution chain: an unmaintained library, a compromised build system, a poisoned package. Tester note: we inventory dependencies and check for known-vulnerable and unmaintained components, and where the build pipeline is in scope we review it, which overlaps with CI/CD pipeline security.
A04: Cryptographic Failures. The absence of, or weakness in, cryptography: sensitive data sent or stored without encryption, weak algorithms like MD5 or SHA-1, hard-coded or reused keys, keys checked into source. Tester note: we check what data needs protecting, whether TLS is enforced everywhere, and how keys are generated and stored.
A05: Injection. Untrusted input reaching an interpreter as commands, which includes SQL, NoSQL, OS command, and LDAP injection, and cross-site scripting (XSS) lives here. OWASP notes injection had the most CVEs of any category. Tester note: we test every input, header, cookie, and parameter with a mix of manual work and fuzzing, and prove impact rather than flagging a reflected character.
A06: Insecure Design. A flaw in the design, not the code, that a perfect implementation cannot fix because the control was never designed. Business-logic abuse lives here: a refund flow a user can trigger on their own account, a limit that is never enforced. Tester note: this is the work automation cannot touch, because it requires understanding what the feature is for. We map the workflows and abuse them the way a motivated user would.
A07: Authentication Failures. Renamed for 2025. Weaknesses that let an attacker be recognized as a legitimate user: credential stuffing and password spraying that are not rate-limited, weak or breached passwords accepted, missing or bypassable MFA, session identifiers exposed in URLs, sessions not invalidated on logout. Tester note: we test login, MFA, session lifetime, and recovery flows, and check them against breached-credential reuse.
A08: Software or Data Integrity Failures. Trusting code or data whose integrity was never verified: an auto-update mechanism with no signature check, deserialization of untrusted data, a CI/CD pipeline that pulls artifacts without verifying them. Tester note: we look for unsigned updates, unsafe deserialization, and integrity gaps in the build and deploy chain.
A09: Security Logging and Alerting Failures. Renamed to stress that logging without alerting is nearly useless. Auditable events not logged, logs that can be tampered with, no alerting on suspicious activity, an application that cannot tell it is under attack. Tester note: during testing we watch whether our activity is logged and whether anything alerts; silence is itself a finding.
A10: Mishandling of Exceptional Conditions. New for 2025. Software that fails to prevent, detect, or respond to abnormal conditions: poor error handling, logic errors, and, worst of all, failing open, where an error leaves the system in a permissive state. Tester note: we push the application into error states and watch what it does, because an application that fails open on an auth check is a critical finding hiding behind a stack trace.
How a test uses the list
The Top 10 is most useful as the structure for a real assessment, not a list to skim. A web application test works through these categories against your actual build, with a person in each role, and reports each finding mapped to the category it belongs to, so your engineers and your auditors can file it without translation. For the exhaustive test-case reference behind the categories, testers use the OWASP Web Security Testing Guide and the OWASP ASVS verification standard, which we cover in our web application security testing guide.
The Top 10 also matters for compliance. When a SOC 2 auditor or an enterprise questionnaire asks for OWASP Top 10 coverage, the report that names each category is the evidence they want, and the same test supports the access-control and injection expectations of most frameworks.
The OWASP family
The web Top 10 is one of several OWASP lists, each for a different surface. If your product spans more than a website, work through the relevant ones:
- OWASP API Security Top 10 for the APIs behind your app, tested as API penetration testing from $4,000.
- OWASP Mobile Top 10 for iOS and Android apps.
- OWASP Top 10 for LLM Applications for chatbots, copilots, and agents.
Frequently asked questions
Is the OWASP Top 10 2025 the current edition? Yes. The 2025 list is the eighth edition of the web application OWASP Top 10, the most recent release. Its categories run A01:2025 through A10:2025, starting with Broken Access Control.
What changed from the 2021 OWASP Top 10? Two new categories and one consolidation. Software Supply Chain Failures (A03) expands the old vulnerable-components entry, and Mishandling of Exceptional Conditions (A10) is entirely new. Security Misconfiguration rose to #2, Broken Access Control held #1 with SSRF folded into it, and two categories were renamed to reflect their content more precisely.
Is the OWASP Top 10 a standard you can be certified against? No. OWASP describes it as an awareness document, not a certification. For a verifiable standard with testable requirements and levels, use the OWASP ASVS. The Top 10 frames the risks; ASVS and the Web Security Testing Guide provide the depth.
Does a penetration test cover the whole OWASP Top 10? A web application penetration test is structured to cover the categories that apply to your application, with each finding mapped to its category. Some, like Insecure Design and Broken Access Control, need manual testing by someone who understands the application; a scanner alone cannot cover the list.
How is the OWASP Top 10 different from the API and Mobile lists? Each targets a different surface. The web Top 10 covers web applications; APIs, mobile apps, and LLM applications each have their own list because their risks differ. A complete assessment of a product with several surfaces uses more than one.
Fixed price, fixed scope, free retest. Web application testing from $5,200, API testing from $4,000, both mapped to the OWASP Top 10. Scope your test and get a written price within one business day.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →