Most application security requirements are either too vague to test ("the application must be secure") or borrowed from an awareness list that was never meant to be a standard. The OWASP Application Security Verification Standard (ASVS) fills that gap: a catalogue of testable application security requirements (security verification requirements, each one pass or fail), grouped into three verification levels. Version 5.0.0, released in May 2025, is a complete reorganisation of 4.0.3, with about 350 requirements in 17 chapters. This guide explains the ASVS verification levels, how chapters and requirement IDs work, what changed from 4.0.3, and how to use the standard for secure development, ASVS assessment and benchmark testing, and procurement, with mappings to the MASVS and the OWASP Top 10. It is for AppSec leads, architects, testers and the people who buy software or testing. The programme view sits in the Application Security Guide; this page goes deeper on the standard itself.
Key takeaways
- ASVS is a requirements standard, not a risk list. OWASP's own Top 10 guidance says to use the ASVS for any application security standard "as it's designed to be verifiable and tested".
- Pick a level per application, not per company. Level 1 is about 20% of requirements, Levels 1 and 2 together about 70%, and Level 3 adds the final 30%; OWASP says most applications should aim for Level 2.
- Always cite the version. Use the form v5.0.0-8.2.2, because requirement numbers changed completely between 4.0.3 and 5.0.0 and may change again.
- Nobody certifies ASVS compliance. OWASP does not certify vendors, verifiers or software and does not endorse third-party ASVS trust marks; ask for the scope, the requirements checked and the evidence instead.
- Automation covers only part of it. OWASP states that scanners cannot fully verify business logic or access control and that black-box testing alone is not enough; Level 2 and 3 verification needs documentation, source code and developers.
What ASVS 5.0 is and what it is not
The OWASP project page describes the ASVS as providing "a basis for testing web application technical security controls". Its scope, set out in the 5.0 chapter "What is the ASVS", covers web applications and services and the security controls built into them, plus HTTP-handling components such as WAFs, load balancers and proxies where they perform specific functions such as caching or rate limiting. It excludes development lifecycle and CI/CD prescriptions, things managed outside the application such as DNS and backups, and functional or code-style rules. Every requirement must have a demonstrable security impact and be verifiable as pass or fail; the standard contains only "must" statements.
- Current version: 5.0.0, dated May 2025 and released at Global AppSec EU Barcelona 2025. The repository's master branch is the "bleeding edge"; the next planned release is a patch, 5.0.1.
- Versioning rules: a major version reorganises the standard and needs re-evaluation; a minor version may add or remove requirements but generally keeps numbering; a patch may only remove or relax requirements, so earlier compliance still holds.
- Formats: PDF, Word, CSV and JSON exports, which is what most teams load into trackers, test management and threat modelling tools.
- Documented security decisions: new in 5.0. Context-dependent controls (permission rules, input validation, session timeouts) must first be documented by the organisation, then implemented, and the verifier checks both. That allows, for example, a longer session timeout paired with other mitigations, as long as the decision is written down.
- Not a secure SDLC: ASVS says what the software must do, not how you build it. Pair it with NIST SSDF and a maturity model. See the Secure Software Development Lifecycle (SSDLC) Guide.
The ASVS verification levels
In 5.0, OWASP assigns levels by weighing risk reduction (confidentiality, integrity, availability, and whether a control is a primary defence or defence in depth) against implementation effort. Testability is no longer the criterion, which is the biggest conceptual change from 4.0.3, where Level 1 was designed around black-box testing. Levels are cumulative: Level 2 compliance means meeting every Level 1 and Level 2 requirement. Some requirements appear at several levels with stricter conditions at the higher one, and higher-level requirements are presented as recommendations to lower-level applications.
| Level | Share of requirements | What it targets | Typical applications | Evidence needed to verify |
|---|---|---|---|---|
| ASVS Level 1 | About 20% (70 of 345 in 5.0.0) | First-layer defences against common attacks that need no other weakness or precondition | Every application as a floor; low-sensitivity internal tools; early-stage products | Testing plus configuration review; source access still strongly preferred |
| ASVS Level 2 | About 50% more (about 70% cumulative) | Less common attacks, stronger protection against common ones, attacks with preconditions | Applications handling personal, financial or business-critical data; most internet-facing services | Documentation, source code, configuration and developer interviews |
| ASVS Level 3 | Final ~30% | Defence in depth and controls that are hard to implement | High-value targets: payments, health, critical infrastructure, identity platforms | As Level 2, with deeper design review and hybrid testing |
Choosing a level: the standard deliberately does not prescribe one. Its own example puts an early-stage startup with little sensitive data at Level 1 and a bank at Level 3. In practice, tie the level to your application risk tiers, set Level 1 as the minimum for everything, and allow individual Level 3 requirements to be pulled forward where the risk justifies it (for example, v5.0.0-8.4.2 layered protection of administrative interfaces). A small organisation with a few applications can adopt Level 1 everywhere and Level 2 for its customer-facing product; a large organisation needs a tiering rule that assigns the level automatically when an application is registered.
Chapters and requirement numbering
Every requirement has an identifier in the form chapter.section.requirement, so 8.2.2 is the second requirement in section 2 (General Authorization Design) of chapter V8. Because identifiers move between versions, OWASP asks documents and tools to prefix the version with a lowercase v: v5.0.0-8.2.2. An identifier without a version means "the latest", which can change underneath you. These are the 17 ASVS requirement areas in 5.0.0.
| Chapter | Covers | Requirements cited in this guide |
|---|---|---|
| V1 Encoding and Sanitization | Output encoding, injection prevention and sanitisation | v5.0.0-1.2.5 (Injection Prevention section) |
| V2 Validation and Business Logic | Input validation (moved here in 5.0) and business logic | None |
| V3 Web Frontend Security | Browser-facing controls (a new chapter split out in 5.0) | None |
| V4 API and Web Service | Generic web services, HTTP message structure, GraphQL, WebSocket | 4.1.4 (L3) only supported HTTP methods; 4.2.1 (L2) message boundaries; 4.3.2 (L2) GraphQL introspection off in production unless public |
| V5 File Handling | Files the application accepts, stores and serves | None |
| V6 Authentication | User authentication; the largest chapter in the CSV export | None |
| V7 Session Management | Session lifecycle | None |
| V8 Authorization | Function, data and field-level access, operation-level enforcement, multi-tenancy | 8.1.1, 8.1.2 documentation; 8.2.1 (L1) function level; 8.2.2 (L1) data level, IDOR and BOLA; 8.2.3 (L2) field level, BOPLA; 8.3.3 (L3); 8.4.2 (L3) |
| V9 Self-contained Tokens | Tokens such as JWTs (moved out of session management, with new requirements) | None |
| V10 OAuth and OIDC | OAuth 2.0 and OpenID Connect implementations (new in 5.0) | None |
| V11 Cryptography | Cryptographic algorithms and key management | None |
| V12 Secure Communication | Protection of data in transit | None |
| V13 Configuration | Secure configuration of the application and its components | None |
| V14 Data Protection | Protection of sensitive data the application handles | None |
| V15 Secure Coding and Architecture | General secure coding and design requirements (new in 5.0) | None |
| V16 Security Logging and Error Handling | Security event logging and error handling | None |
| V17 WebRTC | Real-time communication features (new in 5.0) | None |
Chapter names are from the 5.0.0 CSV export; requirement IDs are listed only where we read the requirement text, so check the current source before building packs. Tailoring is expected: OWASP encourages forks that drop sections you do not use (GraphQL, WebSockets, SOAP) and adjust requirements by risk, provided the fork keeps traceability so an identifier means the same thing everywhere it appears.
Where identity fits: V6, V7, V9 and V10 together are close to a third of the standard, and much of it applies to non-human callers that present tokens and client credentials, not only to people signing in. v5.0.0-8.3.3 (L3) requires access decisions to use the originating consumer's permissions rather than an intermediary's, which is the delegation problem services and AI agents create. See the OAuth 2.0 and OpenID Connect Guide and the Token and Session Security Guide.
What changed from ASVS 4.0.3
OWASP's "For users of 4.0" chapter is candid: of 286 requirements in 4.0.3, only 11 are unchanged and 15 have grammatical edits; 109 (38%) are no longer separate requirements, of which 50 were deleted, 28 removed as duplicates and 31 merged. Two-way mapping files trace each 4.0.3 requirement to 5.0.0 and back.
| Area | ASVS 4.0.3 | ASVS 5.0.0 |
|---|---|---|
| Size | 286 requirements, 14 chapters | 345 requirements, 17 chapters |
| Level 1 | 128 requirements (46%), labelled Minimum, built for black-box testing | 70 requirements (20%), first-layer defences, chosen by risk and effort |
| Architecture | V1 Architecture, Design and Threat Modeling chapter | Removed; content redistributed or out of scope; documented security decisions added |
| New areas | None | OAuth and OIDC; WebRTC; Self-contained Tokens; Web Frontend Security; Secure Coding and Architecture |
| Input validation | With sanitisation and encoding | With business logic (V2) |
| Mappings | Direct CWE and NIST SP 800-63 references | Direct CWE mappings discontinued; NIST mapping no longer maintained; OWASP Common Requirement Enumeration (CRE) mapping planned |
| Wording | Often named specific mechanisms | States the security goal; mechanisms only where they are the sole practical option |
Migrating: do not bulk-rename 4.0.3 IDs. Load the mapping file, re-baseline each in-scope application against 5.0.0 at its chosen level, and treat the drop in Level 1 size as a reason to check whether applications previously "at Level 1" now belong at Level 2.
Using ASVS in secure development
The ASVS is most valuable before code is written. The 5.0 text lists uses for architecture, secure coding guidance, automated abuse-case tests, training and procurement. A workable rollout:
- Tier applications and assign a level from data sensitivity and exposure; record the level in the application inventory.
- Build a fork or requirement pack per tier from the CSV export: remove chapters that do not apply, add organisation-specific notes, keep the v5.0.0 IDs.
- Write the documented security decisions each chapter asks for (for example 8.1.1 authorisation rules and 8.1.2 field-level rules) as part of design and threat modelling. See the Threat Modelling Guide.
- Turn requirements into acceptance criteria and tests: security stories reference the ASVS ID; unit and integration tests cover the technically verifiable requirements. OWASP notes "testable using automation != running an off the shelf tool".
- Pilot on one product team for a release cycle, measure effort and false starts, then adjust the pack before extending it.
- Verify at release with a hybrid assessment for Level 2 and 3 applications, and track exceptions with an owner and expiry.
- Roll back sensibly: if a requirement blocks delivery without a workable control, record a time-limited exception rather than silently dropping it from the pack.
The Secure Coding Guide covers the developer practices that most V1, V2 and V15 requirements depend on.
ASVS assessment and benchmark testing
OWASP's assessment chapter sets out what a credible ASVS assessment looks like. The verifier states the target level and lists the requirements in scope, describing scope by what was included and explaining any exclusions. Findings carry evidence (work papers, screenshots, scripts, test logs) and the methods are disclosed and repeatable. Unlike a penetration test report that lists only failures, an ASVS report includes the scope, a summary of every requirement checked, the exceptions and remediation guidance, and marks non-applicable requirements explicitly (session management in a stateless API is OWASP's example).
- Testing approach: OWASP discourages black-box testing and strongly encourages hybrid testing with access to documentation, source and developers. SAST and DAST, properly tuned, catch some basics such as output encoding but cannot fully verify access control or business logic. See the Web Application Security Testing Guide.
- ASVS benchmark across a portfolio: use the same pack, the same pass, fail and not-applicable rules and the same evidence standard for every application, then report coverage per chapter and level. That turns "ASVS benchmark testing" from a one-off audit into a comparable baseline you can trend quarterly and use to compare business units or suppliers.
- Benchmarking tools and providers: ask scanners and testing firms which ASVS requirement IDs their output maps to, and how. OWASP's Top 10 guidance says "The ASVS is the only acceptable choice for tool vendors", and coverage claims should be per requirement, not per chapter.
- ASVS checklist use and ASVS compliance: a spreadsheet of requirements is a useful tracking aid, but ticking boxes without evidence is not verification. Every "pass" needs a recorded test or document reference. ASVS compliance at a level means every in-scope requirement at that level and below passed, with exclusions explained; there is no official certificate behind the claim.
| Metric | How to measure | What good looks like |
|---|---|---|
| Level coverage | Applications verified at their assigned level in the last 12 months | All tier 1 applications; rising quarterly for the rest |
| Requirement pass rate | Passed / (passed + failed), excluding not applicable, per chapter | Weakest chapters improving release on release |
| Open exceptions | Failed requirements with an approved exception, by age | None past expiry |
| Automated coverage | Requirements with an automated test in CI | Most Level 1 requirements |
| Time to close | Median days from failed requirement to verified fix | Within the remediation SLA for its severity |
| Escape rate | Production findings that map to a requirement marked passed | Falling; each escape triggers a test fix |
ASVS for procurement and supplier assurance
The 5.0 text names procurement directly: a buyer can require software to meet a specified level and ask the seller to demonstrate it. NIST SSDF (SP 800-218) gives acquirers "a common vocabulary for secure software development" for the process side; ASVS supplies the product side.
- Contract wording: require "OWASP ASVS v5.0.0 Level 2, verified by an independent hybrid assessment within 12 months of delivery", plus remediation timelines for failed requirements and re-verification after major releases.
- What to ask for: the tailored requirement list, the assessment report with scope and all requirements checked, the documented security decisions and the exception register.
- Red flags: an "ASVS certified" badge (OWASP does not certify), version-less claims, scope described only by exclusions, or a scanner report presented as ASVS compliance.
- Testing providers: when you buy a test against ASVS, specify the level, require source and documentation access, and ask for results in ASVS IDs. See the Application Security Testing Buyer's Guide and the Penetration Testing Guide.
ASVS mapping: MASVS, OWASP Top 10 and frameworks
ASVS vs MASVS: the Mobile Application Security Verification Standard covers the app on the device; the MASVS text itself says the ASVS "should be used to ensure that the server is secure". A mobile product therefore needs both.
| Aspect | OWASP ASVS 5.0.0 | OWASP MASVS |
|---|---|---|
| Target | Web applications, APIs and services | iOS and Android apps |
| Structure | 17 chapters, about 350 requirements | 8 control groups, 24 controls (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY) |
| Rigour model | Levels 1 to 3 | Former L1, L2 and R levels reworked as MAS Profiles |
| Testing companion | ASVS assessment chapter guidance | MASTG test cases and MASWE weaknesses |
| Procurement use | Buyer requires a level, seller demonstrates | "a baseline for mobile app security verification during procurement" |
See the Mobile App Security Testing Guide for MASVS-based testing.
ASVS and the OWASP Top 10: the Top 10 is an awareness document; OWASP "discourages any claims of full coverage of the OWASP Top 10". Use the Top 10:2025 categories to explain risk to executives and ASVS chapters to define and test the fix. Our mapping: A01 Broken Access Control to V8 (and V1 for SSRF, which the 2025 list rolled into A01); A02 Security Misconfiguration to V13 and V3; A03 Software Supply Chain Failures to V15 and V13; A04 Cryptographic Failures to V11 and V12; A05 Injection to V1 and V2; A06 Insecure Design to V2, V15 and the documentation requirements; A07 Authentication Failures to V6, V7, V9 and V10; A08 Software or Data Integrity Failures to V15; A09 Security Logging and Alerting Failures to V16; A10 Mishandling of Exceptional Conditions to V16 and V2. See the OWASP Top 10 Guide.
Frameworks: ASVS is the requirement catalogue behind ISO/IEC 27001:2022 Annex A 8.26 (application security requirements) and 8.29 (security testing in development and acceptance), and 8.30 when development is outsourced; NIST SSDF PO.1 (define security requirements); NIST SP 800-53 SA-4 (acquisition process) and SA-11 (developer testing and evaluation); NIST CSF 2.0 PR.PS-06 (secure software development); and CIS Controls v8.1 Control 16, notably 16.1 secure development process and 16.13 application penetration testing.
Common failure patterns
- Level 3 everywhere: setting the strictest level for every application guarantees exceptions and erodes trust in the standard. Tier first.
- Version-less requirement IDs: tickets that say "ASVS 2.1.1" now point at a different requirement than they did under 4.0.3. Always use the v5.0.0 prefix.
- Scanner output called ASVS compliance: automated tools cannot verify most V8 and V2 requirements, which is where authorisation flaws live.
- APIs outside scope: assessing the user interface but not the APIs behind it. The McKinsey AI platform hack came through unauthenticated APIs that V4, V6 and V8 requirements would have covered.
- Skipping documented decisions: without 8.1.1-style written rules, testers cannot tell whether an access check is wrong or merely undocumented, and results become opinion.
- A one-off assessment: a single pre-launch report with no re-verification after major releases decays within months.
Practitioner checklist
- Adopt ASVS 5.0.0 and cite every requirement in versioned form (v5.0.0-x.y.z).
- Assign an ASVS level to each application from its risk tier, with Level 1 as the floor and Level 2 for anything handling personal or financial data.
- Build tailored requirement packs from the CSV export and keep traceability to the official IDs.
- Write the documented security decisions (authorisation, field-level access, validation, session rules) during design.
- Automate tests for technically verifiable requirements and record which requirements each test covers.
- Require hybrid assessments with source and documentation access for Level 2 and 3 applications, reported against every in-scope requirement.
- Write ASVS level, verification evidence and re-verification into supplier and testing contracts; reject certification badges as evidence.
- Use the MASVS for mobile clients and the ASVS for their back ends.
- Report level coverage, pass rate per chapter and open exceptions quarterly.
Standards and references
- OWASP: Application Security Verification Standard (ASVS) project
- OWASP: ASVS repository README (5.0.0 release and reference format)
- OWASP: ASVS 5.0 What is the ASVS (levels, scope and uses)
- OWASP: ASVS 5.0 Assessment and Certification
- OWASP: ASVS 5.0 For Users of 4.0
- OWASP: Using the MASVS
- OWASP: How to use the OWASP Top 10 as a standard
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
Related NHI Mgmt Group resources: Application Security Guide · OWASP Top 10 Guide · Mobile App Security Testing Guide · Secure Software Development Lifecycle (SSDLC) Guide · API Security Guide