OWASP ASVS vs Top 10 (2025): Verification Standard vs Awareness List

The OWASP® Top 10 and the OWASP ASVS often get treated as two versions of the same thing, and they are not. The Top 10 tells you which risks deserve attention; the ASVS tells you what your application must do and how to check that it does. Mixing them up is how a team ends up calling itself "Top 10 compliant", a claim OWASP says cannot be true.

The OWASP Top 10 is a ranked list of the ten most critical security risk categories for web applications, published to raise awareness. The Application Security Verification Standard (ASVS) is a list of security requirements that architects, developers, testers, tool vendors and buyers use to define, build, test and verify secure applications.

A risk category groups related weaknesses, each identified by a CWE, an entry in the Common Weakness Enumeration catalogue of software weakness types. A requirement is a single statement that an application either meets or does not.

The Top 10:2025 is the eighth edition, presented at OWASP Global AppSec USA in November 2025. ASVS 5.0.0 was released on 30 May 2025 with 345 requirements in 17 chapters.

OWASP ranked the 2025 categories on data from more than 2.8 million applications and let its community survey promote two of them, A03 and A09 (introduction). Together the ten categories cover 248 CWEs. The third column below is my own chapter-level mapping to ASVS 5.0, built from the ASVS chapter files; it is not an official OWASP mapping.

Three of these changes deserve a closer look:

• SSRF moved. Server-side request forgery, A10:2021, is now part of A01:2025 Broken Access Control. The ASVS requirement for it, v5.0.0-1.3.6, sits in the sanitization section of V1.
• Supply chain got wider. A03:2025 extends the old outdated-components category to the build and distribution ecosystem. The ASVS covers the application's components (V15), but it does not prescribe lifecycle or CI/CD pipeline activities, so the build side needs another source.
• Logging now means alerting. A09:2025 was renamed because logs that never raise an alert are of little value. ASVS 5.0 keeps security event logging in scope but leaves alerting and correlation to operational monitoring.

The mapping is not one-to-one, and that is the point: the two documents answer different questions. Some Top 10 pages list related ASVS sections in their references (A10:2025 points to V16.5), and ASVS 5.0 dropped direct mappings to other standards in favor of a planned link through OpenCRE.

No, and OWASP says so. The Top 10:2025 describes itself as "primarily an awareness document" (Establishing a Modern Application Security Program). Teams have treated it as a de facto standard since 2003, so the same page spells out what that means: if you adopt it as a coding or testing standard, treat it as the floor, a starting point rather than a complete set of requirements.

The page gives three reasons:

• It documents risks, not necessarily issues that are easy to test. Most forms of testing cannot reach A06:2025 Insecure Design, and checking logging takes interviews and sampled incident responses.
• No tool can fully detect, test for or protect against the Top 10 risks, so OWASP discourages any claim of full Top 10 coverage and calls such claims untrue.
• For anyone who needs a standard, OWASP recommends the ASVS because it is built to be verified and tested, and it tells tool vendors to use nothing else.

Its use-case table makes the split plain. The Top 10 suits awareness and entry-level training, but rates only as a minimum for coding standards, code review, penetration testing and tool support; the ASVS gets a yes in every one of those rows.

Every ASVS requirement must be verifiable, with a pass or fail result (What is the ASVS?). The rest of the design follows from that:

• Levels. Level 1 holds about 20% of the requirements, the first layer of defense. Level 2 adds about 50%, so meeting it means about 70% of the standard, and the ASVS says most applications should aim for it. Level 3 adds the remaining defense-in-depth controls. You pick the level from your own risk assessment.
• Stable identifiers. Requirements are numbered chapter.section.requirement and should be cited with the version, for example v5.0.0-6.2.1 for minimum password length.
• Procurement. A buyer can require software built to ASVS Level X and ask the seller to prove it.
• Forks. OWASP encourages organization- or domain-specific forks, as long as they keep traceability to the original IDs.

What it is not: OWASP certifies no vendors, verifiers or software, so "ASVS certified" is a third-party label at best. The same chapter warns against black-box-only testing and says scanners alone cannot verify many of the more complex requirements. For a chapter-by-chapter tour, see OWASP ASVS 5.0 explained.

Earlier in my career, at a payment facilitator, we secured the merchant and gateway APIs against the OWASP Top 10 risks with input validation, rate limiting, authentication and encryption. The Top 10 was a good fit for that: it named the risk classes, and we chose controls for each. But a risk category has no pass condition, so "secured against the Top 10" described our intent rather than something a reviewer could check line by line.

On a multi-tenant payment aggregator I work on now, I built the admin and merchant sign-in against 13 OWASP ASVS 5.0 controls, which came to 40 requirements and 96 test scenarios. That is the practical difference: a requirement becomes an acceptance criterion with a test behind it, while a risk category can only become a goal. I cover the authentication side in Implementing ASVS 5.0 authentication in a payments API.

Use each document for the question it answers.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

1. Awareness and prioritization: Top 10. Put the Top 10:2025 in onboarding and threat-modeling sessions, and use it to decide which ASVS chapters to work through first. On a payments API, A01 and A07 point straight at V8 Authorization and V6 Authentication.
2. Requirements: ASVS. Pick a level per application, then write versioned ASVS IDs into tickets as acceptance criteria. Use the same list in vendor contracts and to define what your scanners and reviews must cover.
3. Testing: WSTG. The OWASP Web Security Testing Guide (WSTG) is OWASP's methodology for testing web applications; v4.2 is the stable release and v5.0 is in development. Use it to design test cases per requirement, next to the unit and integration tests the ASVS itself recommends. The wider toolbox is in Beyond ASVS.

If you are in PCI DSS scope, Requirement 6.2.1 expects bespoke and custom software to follow recognized secure-development standards or good practice (Microsoft's Requirement 6 guide). In my reading, a named ASVS level is a much stronger answer to that than "we follow the Top 10"; I map the two in Mapping OWASP ASVS to PCI DSS Requirement 6.

There is nothing to comply with. OWASP calls full-coverage claims untrue and certifies no one. When a vendor or a pen-test report says it "covers the OWASP Top 10", ask which ASVS version and level were verified, against what scope, and how.

Ten boxes feel complete, but they stand for 248 CWEs, and one of them, A06:2025 Insecure Design, cannot be ticked off by testing at all. If you need a checklist, ASVS Level 1 is 70 requirements, each with a pass condition.

"A02" meant Cryptographic Failures in 2021 and means Security Misconfiguration in 2025; "A10" went from SSRF to Mishandling of Exceptional Conditions. ASVS numbers drift too: v4.0.3-2.1.1 was the 12-character password minimum, while v5.0.0-2.1.1 asks for documented input validation rules. Write A02:2025 and v5.0.0-2.1.1 in tickets, reports and contracts, every time.

ASVS 5.0 no longer picks Level 1 requirements for how easily they can be tested from outside (changes for 4.x users). Many requirements need documentation or source code to verify, so give testers both.

• Replace "OWASP Top 10" in security requirements, RFPs and contracts with "ASVS 5.0.0 Level N" plus a defined scope.
• Choose a level per application. Level 2 is where the ASVS says most applications belong; I would not go below it for anything that moves money.
• Turn the ASVS chapters behind your top Top 10 risks into tickets with versioned IDs as acceptance criteria, starting with V6, V7 and V8 for sign-in and admin access.
• Update training material that still lists SSRF as A10, and teach the Top 10:2025 as awareness, not as the definition of done.
• Tag every finding twice: the failed ASVS requirement for the fix, the Top 10:2025 category for reporting.

Quoted text from the OWASP Top 10:2025, (c) OWASP Foundation, licensed CC BY-SA 4.0.