Overview
The OWASP Application Security Verification Standard (ASVS) is an open, community-driven framework of security requirements for web applications and web services. Rather than telling you which tool to run, it defines what a secure application must do — providing a normalized, testable list of controls that developers, architects, and testers can use as a single source of truth.
ASVS serves two primary purposes: it gives organizations a metric to gauge the degree of trust that can be placed in their applications, and it gives guidance to anyone building or assessing security controls on exactly what to implement and verify. Each requirement is written so it can be objectively tested, making it suitable for both manual review and as input to automated tooling.
ASVS aims to normalize the range of coverage and level of rigor available when it comes to performing web application security verification.
Verification Levels
ASVS defines three increasing levels of verification rigor. You select a target level based on the risk and value of the application, then verify that it meets every requirement at and below that level. Level 5.0 rebalanced the levels so L1 has a lower barrier to entry while L3 grew substantially with high-assurance controls.
- Level 1 (Opportunistic / Basic): the minimum baseline that every application should meet. Designed to be largely black-box testable without access to source code, configuration, or developers — suitable for low-assurance apps and as a first step for everyone.
- Level 2 (Standard / Recommended): the level appropriate for most applications that handle sensitive data and business-critical functions. It defends against the majority of risks present in software today and is OWASP's recommended target for most projects.
- Level 3 (Advanced / High-assurance): for the most critical applications — those performing high-value transactions, holding sensitive medical data, or requiring the highest levels of trust. It demands deep, thorough verification including new high-assurance controls added in 5.0.
Chapter Structure (ASVS 5.0)
ASVS 5.0 (released May 2025) reorganized and renumbered the standard into 17 chapters, each grouping related requirements. Requirements use a <chapter>.<section>.<requirement> numbering format (e.g. 1.2.5). The standard contains roughly 350 individual, testable controls across these chapters.
- V1 Encoding and Sanitization — output encoding, injection prevention, and safe handling of untrusted data
- V2 Validation and Business Logic — input validation and business-logic integrity
- V3 Web Frontend Security — browser-side protections, headers, CSP, and frontend hardening
- V4 API and Web Service — REST, GraphQL, and web service security
- V5 File Handling — secure upload, storage, and processing of files
- V6 Authentication — credential and authenticator lifecycle, including password rules
- V7 Session Management — session lifecycle, tokens, and timeouts
- V8 Authorization — access control and enforcement of permissions
- V9 Self-contained Tokens — JWT and other stateless token security
- V10 OAuth and OIDC — OAuth 2.0 / OpenID Connect authorization-server and client controls (heavily expanded in 5.0)
- V11 Cryptography — algorithms, key management, and post-quantum planning
- V12 Secure Communication — TLS and transport-layer protection
- V13 Configuration — secure defaults, secrets, and dependency/build configuration
- V14 Data Protection — confidentiality, privacy, and protection of sensitive data
- V15 Secure Coding and Architecture — architectural and coding-level defenses, including malicious-code concerns
- V16 Security Logging and Error Handling — logging, monitoring, and safe error handling
- V17 WebRTC — security requirements specific to real-time communications
Note: ASVS 5.0 removed the direct mappings to MITRE CWE that earlier versions carried (some links were ambiguous), with future cross-references planned via OWASP's Common Requirement Enumeration (CRE). The previous 4.0 structure used 14 chapters (V1 Architecture through V14 Configuration) with each requirement mapped to a CWE.
How to Use ASVS
- As a verification checklist: pick a target level (L1/L2/L3) and assess each requirement to produce a coverage report.
- To drive secure design: use the requirements as architectural and security-story inputs early in the SDLC, baking controls into the design rather than bolting them on.
- In procurement and contracts: specify an ASVS level as an objective, testable acceptance criterion for software you buy or commission.
- For testing and assurance: combine ASVS (the 'what') with the OWASP Web Security Testing Guide / WSTG (the 'how to test') to plan and execute assessments.
- Alongside the OWASP Top 10: the Top 10 raises awareness of the most critical risks, while ASVS provides the detailed, measurable requirements needed to actually defend against them.
Version History
ASVS has evolved steadily since 2008, with each major version expanding coverage and refining the requirement structure.
- 1.0 (2008–2009): first release establishing the verification-standard concept.
- 2.0 (Aug 2014): refreshed requirement set and structure.
- 3.0 / 3.0.1 (2015–2016): reorganized chapters and broadened coverage.
- 4.0 (Mar 2019): major rework into 14 chapters (V1–V14) with the three-level model and CWE mappings.
- 4.0.2 (Oct 2020) and 4.0.3 (Oct 2021): maintenance releases with fixes and clarifications.
- 5.0.0 (May 30, 2025): launched at Global AppSec EU Barcelona — full reorganization into 17 chapters, rebalanced L1–L3, expanded OAuth/OIDC coverage, post-quantum crypto planning, and removal of direct CWE mappings.
ASVS is led by Daniel Cuthbert, Elar Lang, and Josh Grossman, supported by an active working group and a broad community of contributors. It is published free of charge under the Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0) license.