OWASP ASVS 5.0 Application Security Verification Standard Guide
An in-depth technical guide to OWASP ASVS 5.0, covering Level 1 to Level 3 verification baselines, 17 security chapters, and penetration testing methodologies for modern web applications.
- Target Audience
- Software development teams, security architects, DevSecOps engineers, and penetration testers assessing web applications and cloud services
- Mandatory Frequency
- Continuous verification within CI/CD pipelines, supplemented by annual penetration testing or prior to major software releases
- Required Scope
- 17 security chapters (V1 to V17) covering architecture, authentication, access control, cryptography, tokens, APIs, and WebRTC
- Non-Compliance Risk
- Business logic vulnerabilities, authorization bypasses (BOLA/BFLA), token counterfeiting, and enterprise procurement disqualification
The Three Verification Levels (L1, L2, L3) in ASVS 5.0
Stratified application security verification aligned with organizational risk, from automated baselines to critical infrastructure.
An explanatory overview. Read the article for scope, applicability and supporting evidence.
- L1: first-layer defence — Start with essential requirements
- L2: broader coverage — Combine L1 and L2 requirements
- L3: defence in depth — Include applicable requirements at all levels
- Level 1 (L1 - Baseline): Essential baseline security for all applications, mitigating opportunistic and automated threats (70 requirements, ~20% of the standard). Verifiable via black-box penetration testing and gray-box verification without full source access.
- Level 2 (L2 - Standard): Standard verification baseline for business applications processing PII, financial transactions, or sensitive corporate data. Requires defense-in-depth, threat modeling, business logic analysis, and secure code review (cumulative ~70% of total controls).
- Level 3 (L3 - Advanced): Maximum security assurance for critical information infrastructure (CII), military, high-value financial transfers, and life-critical systems. Mandates multi-layered defensive controls, strict architectural compartmentalization, and 100% verification coverage (345 requirements).
- Documented Security Decisions: ASVS 5.0 introduces explicit upfront security decision documentation requirements at the beginning of core chapters, ensuring security design choices remain auditable throughout the application lifecycle.
17 Security Chapters and Modern Architectural Enhancements in ASVS 5.0
Categorization of V1 through V17 verification chapters, featuring dedicated controls for modern tokens, federated identity, and real-time communications.
An explanatory overview. Read the article for scope, applicability and supporting evidence.
- V1 — Encoding and Sanitization
- V2 — Validation and Business Logic
- V3 — Web Frontend Security
- V4 — API and Web Service
- V5 — File Handling
- V6 — Authentication
- V7 — Session Management
- V8 — Authorization
- V9 — Self-contained Tokens
- V10 — OAuth and OIDC
- V11 — Cryptography
- V12 — Secure Communication
- V13 — Configuration
- V14 — Data Protection
- V15 — Secure Coding and Architecture
- V16 — Security Logging and Error Handling
- V17 — WebRTC
- Dedicated Chapters for Self-contained Tokens (V9) and OAuth/OIDC (V10): ASVS 5.0 establishes separate domains for JWT, PASETO, and federated identity flows, enforcing cryptographic signature validation, claim verification, and token lifecycle policies.
- Real-Time Communications via WebRTC (V17): New verification requirements for peer-to-peer data channels, media transport security, signaling authorization, and mandatory DTLS/SRTP encryption.
- Secure Coding and Architecture (V15): Upfront verification of architectural security, explicit trust boundaries, least-privilege compartmentalization, and attack surface minimization.
- Security Logging and Error Handling (V16): Rigorous standards for tamper-resistant audit trails, protection against log injection, and strict prevention of sensitive PII or credentials in log streams.
Integrating ASVS into DevSecOps Pipelines and Software Attestation
Practical implementation of ASVS 5.0 across penetration testing, automated security gates, and audit evidence delivery.
Tools support verification, but assessed requirements need evidence. OWASP does not certify applications or assessors.
- Define scope — Select level and applicable requirements
- Use supporting tools — Review code and configuration
- Perform manual verification — Test access and business logic
- Remediate and report — Retest and record results and limitations
- Target Verification Level Scoping: Establish the target ASVS level (L1, L2, or L3) during system conception, translating requirements into enforceable acceptance criteria within the Secure SDLC.
- Hybrid Verification Pipeline: Combine automated SAST, DAST, and SCA tooling in CI/CD pipelines with manual, independent penetration testing to comprehensively audit V2 business logic and V8 authorization controls.
- Audit-Ready Verification Reports: Generate structured attestation documentation mapping test outcomes directly to ASVS clause IDs, complete with proof-of-concept logs, clean retest records, and formally approved risk exceptions.
- Harmonization with Global Standards: ASVS 5.0 provides the granular technical verification criteria required by ISO/IEC 27001 (A.8.29), SOC 2 Type II (CC7.1), PCI DSS v4.0.1 (Requirements 6 & 11), and national standards.
Requirements and Testing Scope Matrix
Summary of the referenced clauses, the testing scope they cover, and the expected evaluation cycle.
| Reference | Mandate Title | Scope Required | Testing Cycle |
|---|---|---|---|
| ASVS Level 1 (L1 - Baseline) | Essential Baseline Application Security Verification | Protects against common opportunistic threats (70 requirements) covering configuration, access control, and input validation without source code | Prior to initial release (Pre-go-live) and at least annually |
| ASVS Level 2 (L2 - Standard) | Standard Application Security Verification for Sensitive Data | Covers applications handling PII or financial transactions; requires threat modeling, secure code review, and defense-in-depth (cumulative ~70% of controls) | Prior to major application releases and reviewed annually |
| ASVS Level 3 (L3 - Advanced) | Advanced Security Verification for Critical Infrastructure | Critical Information Infrastructure and high-value financial transfers; mandates multi-tier defenses, modular isolation, and 100% coverage (345 requirements) | Comprehensive audit during architectural reviews and ongoing risk cycles |
| ASVS Chapter V9 & V10 | Self-contained Tokens and OAuth / OpenID Connect Verification | Cryptographic validation of JWT/PASETO signatures, token lifecycles, scope enforcement, replay mitigations, and redirect URIs | Evaluated whenever identity providers, authentication flows, or API gateways change |
Compliance Readiness Self-Assessment
Select items your organization has completed to evaluate your readiness score.
Frequently Asked Questions (FAQ)
Key answers and practical guidance addressing common compliance questions.
How does OWASP ASVS 5.0 differ from the OWASP Top 10?
The OWASP Top 10 is an awareness document highlighting the ten most prevalent web application security risks. In contrast, OWASP ASVS is an exhaustive technical standard comprising 17 chapters and 345 specific verification requirements designed as an actionable baseline for designing, building, and formally auditing secure applications.
How should organizations decide between ASVS Level 1, Level 2, and Level 3?
Level 1 serves as the universal baseline for all applications and can be verified via black-box testing. Level 2 is the recommended standard for commercial applications processing PII or financial transactions. Level 3 is reserved for critical information infrastructure (CII), defense, or high-value transactional systems where security failures threaten business survival or public safety.
Does ASVS verification require source code access?
Level 1 verification can be achieved without source code access using black-box and gray-box penetration testing. However, Levels 2 and 3 explicitly mandate white-box access, including source code, architecture documentation, and developer interviews, to verify defense-in-depth controls and business logic implementation.
