OWASP ASVS

Introduction: The OWASP Application Security Verification Standard

The OWASP Application Security Verification Standard (ASVS) is the industry's most widely adopted open framework for specifying, building, verifying and procuring secure web applications and web services. Unlike prescriptive tick-box regulations, ASVS is a technical control catalogue that answers a deceptively simple question: 'How much security does this application actually need, and how do I prove it has been achieved?' It provides a graduated hierarchy of testable requirements that engineering teams, penetration testers, procurement officers and auditors can all rally around a shared, unambiguous definition of what 'secure enough' means for a given application.

For CyberSigma clients, ASVS is invaluable because it is simultaneously a design specification, a secure-coding contract, a functional test plan and a penetration-testing rubric. Where compliance mandates such as PCI DSS, DPDP, ISO 27001 or SOC 2 tell you that applications must be 'secure', they rarely tell your developers precisely which authentication, session, access-control, cryptographic and input-validation controls to implement. ASVS closes that gap. It converts abstract governance obligations into concrete, verifiable engineering requirements that can be embedded into user stories, code review gates, CI/CD pipelines and third-party assurance reports.

This guide provides an auditor-grade deep dive into ASVS: its structure, its verification levels, every control domain, a master assessment checklist mapping each family to what a verifier must confirm and the evidence they should expect, plus a phased implementation approach, scoping guidance, audit methodology, evidence request lists, RACI, KPIs and mappings to adjacent frameworks. It reflects the modernised ASVS structure (v4.0.3 lineage through the v5.0 reorganisation) and is written for teams that must both build to ASVS and be assessed against it.

What is OWASP ASVS

OWASP ASVS is a catalogue of application security requirements, organised into control domains (chapters), each containing groups of related requirements (sections/families), each of which contains individually numbered, testable verification requirements. Every requirement is a positive assertion that can be answered 'verified' or 'not verified' against a target application. The standard is deliberately framed as verification requirements rather than vulnerabilities: instead of saying 'the application must not be vulnerable to SQL injection', ASVS says 'verify that the application uses parameterised queries or equivalent for all database access', which is directly testable and buildable.

ASVS serves several distinct audiences with a single artefact. Architects use it as a security requirements baseline during design. Developers use it as a secure-coding specification. Security testers and penetration testers use it as a coverage checklist so their testing is comprehensive and repeatable. Procurement and vendor-risk teams use it to define the security bar in contracts and RFPs ('the delivered system shall meet ASVS Level 2'). Auditors and assurance providers use it as a maturity benchmark and evidence framework.

Three defining characteristics distinguish ASVS from other application security resources. First, it is levelled: requirements are assigned to Level 1, 2 or 3, so effort scales with application risk. Second, it is verifiable: each requirement is written so a competent tester can determine pass/fail with defined evidence. Third, it is holistic: it spans the full stack, from architecture and authentication through cryptography, error handling, malicious-code resistance, business logic, files, API security, configuration and, in newer editions, the software supply chain.

ASVS is complemented by companion OWASP projects: the OWASP Testing Guide (WSTG) provides the how-to test procedures, the Proactive Controls provide developer-friendly implementation guidance, the Cheat Sheet Series provides deep implementation detail per topic, and the Mobile Application Security Verification Standard (MASVS) provides the equivalent for mobile apps. CyberSigma typically deploys ASVS as the verification backbone and pulls in WSTG and the Cheat Sheets for execution.

Who must comply with (or should adopt) OWASP ASVS

ASVS is a voluntary standard: no law mandates it by name. However, a broad range of organisations adopt it either directly or because a regulator, customer or auditor requires 'a recognised secure development standard'. ASVS is the default choice for most application-centric organisations. The table below summarises who should adopt it and at which typical level.

In short: if you build or buy custom software that processes data of any sensitivity, ASVS applies to you. The only real decision is which verification level each application should target, driven by the data it handles and the impact of its compromise.

Structure of OWASP ASVS

ASVS is organised as a three-tier hierarchy: Chapters (control domains, historically numbered V1 to V14 in the v4 lineage) contain Sections (control families), which contain individual numbered Verification Requirements. Each requirement carries a level assignment (L1/L2/L3) and, in modern editions, a mapping to CWE. The v4.0.x structure comprises fourteen chapters; the v5.0 reorganisation consolidates and renames several chapters (for example splitting web frontend concerns, elevating self-contained tokens, and formalising secure communication and configuration), but the underlying control themes are stable. The table below presents the canonical v4 chapter set, which remains the most widely referenced mapping baseline, with notes on v5 evolution.

Alongside the chapters, ASVS defines three Verification Levels (detailed later) that determine which requirements apply. A requirement present at L1 also applies at L2 and L3 (levels are cumulative). The combination of chapter + level gives every application a precise, contractual security specification.

Master assessment checklist

This is the operational heart of the guide. Below, every ASVS control domain is enumerated with its constituent families. For each, the checklist states what a verifier must confirm and the typical evidence they should collect. Use this as both a build specification and an audit workpaper. Requirement identifiers below follow the v4 chapter numbering; map to your current release before formal sign-off.

V1 - Architecture, Design and Threat Modelling

V2 - Authentication

V3 - Session Management

V4 - Access Control

V5 - Validation, Sanitisation and Encoding

V6 - Stored Cryptography

V7 - Error Handling and Logging

V8 - Data Protection

V9 - Communication

V10 - Malicious Code

V11 - Business Logic

V12 - Files and Resources

V13 - API and Web Service

V14 - Configuration

Scoping an ASVS assessment

Scoping is the single most important determinant of an ASVS engagement's value. Getting it right ensures effort is proportionate to risk; getting it wrong either wastes budget on low-risk assets or leaves critical flows unverified. Scoping proceeds along three axes: which applications, which components and which verification level.

First, define the application boundary. An ASVS 'application' includes its web/API frontends, backend services, databases, message queues, third-party integrations and the deployment configuration that binds them. Clearly document trust boundaries, data flows, authentication surfaces and where sensitive data is processed or stored. Micro-frontends and microservices should each be attributed to the application scope so no service is orphaned.

Second, select the verification level per application based on the data it handles and the impact of compromise. Applications handling only public or low-value data may target L1; applications processing personal data, financial transactions or B2B data typically target L2; applications where compromise causes serious harm (payments core, healthcare records, critical infrastructure, identity providers) target L3. It is common and sensible to run an application at L2 overall while elevating specific high-risk flows (authentication, cryptography, payment) to L3 requirements.

Third, define what is in and out of scope for testing. Third-party SaaS components you consume but do not control are typically covered by vendor assurance rather than direct ASVS testing, though their integration points remain in scope. Legacy systems scheduled for decommission may be risk-accepted. Document all exclusions with justification so the resulting attestation is honest and defensible.

Implementation approach (phased)

CyberSigma implements ASVS as a programme, not a one-off audit. The following five phases move an organisation from ad hoc security to repeatable, level-verified assurance embedded in the SDLC.

Phase 1 - Baseline and level assignment

Establish where you stand and what each application must achieve.

• Activities: inventory applications and services; classify data handled; assign an ASVS level to each application; perform a rapid gap self-assessment against the assigned level; identify quick wins and critical gaps.
• Deliverables: application inventory with level assignments, data classification matrix, initial gap register, prioritised remediation backlog.

Phase 2 - Requirements integration

Embed ASVS into how software is specified and built.

• Activities: translate the assigned-level requirements into engineering standards, definition-of-done criteria and security user stories; add ASVS-aligned checks to code review and design review; select supporting tooling (SAST, DAST, SCA, secret scanning).
• Deliverables: ASVS-derived secure-coding standard, security requirement templates, updated definition of done, tooling integrated into the pipeline.

Phase 3 - Remediation and control build-out

Close the gaps identified in the baseline.

• Activities: remediate prioritised gaps by domain (authentication, access control, crypto, input handling); implement centralised, reusable security controls; harden configuration and dependencies; establish threat modelling for high-risk apps.
• Deliverables: remediated controls with evidence, shared security library/framework, threat models, hardened baselines.

Phase 4 - Verification and testing

Prove each requirement is met at the assigned level.

• Activities: execute manual and automated verification per the master checklist; run penetration testing scoped to the ASVS level; validate control effectiveness; record pass/fail per requirement with evidence.
• Deliverables: completed ASVS verification workbook, penetration test report, evidence pack, residual-risk register.

Phase 5 - Continuous assurance

Sustain the level across future releases.

• Activities: gate releases on ASVS checks in CI/CD; re-verify on significant change; track metrics; schedule periodic reassessment and threat-model refresh; feed findings back into standards.
• Deliverables: automated ASVS gates, KPI dashboard, reassessment schedule, continuous-improvement loop.

Verification levels (ASVS scoring model)

ASVS defines three cumulative verification levels. Each higher level includes all requirements of the levels below it, plus additional, more rigorous controls. The level chosen expresses the assurance an application requires and is the primary 'score' in ASVS: an application is verified as meeting L1, L2 or L3 (fully) for its declared scope.

Because levels are cumulative, an L3 verification means every L1, L2 and L3 requirement in scope is met. Partial results are reported per requirement (verified / not verified / not applicable) so stakeholders see exactly which controls pass. CyberSigma reports both the headline level achievement and a domain-by-domain pass rate so remediation can be targeted.

Assessment and audit approach

A rigorous ASVS assessment blends documentation review, configuration analysis, code review, dynamic testing and penetration testing. CyberSigma follows a structured, repeatable methodology so results are consistent and defensible.

1. Confirm scope and level: agree the application boundary, components and target ASVS level with stakeholders; document trust boundaries and data flows.
2. Gather documentation: collect architecture diagrams, threat models, policies, prior test reports and the requirement/level assignment.
3. Prepare the verification workbook: instantiate the applicable requirements for the assigned level as a pass/fail workbook with evidence fields.
4. Perform static verification: review source code, configuration and dependencies against relevant requirements (auth, crypto, input handling, config).
5. Perform dynamic verification: exercise the running application, capturing headers, session behaviour, access-control responses and error handling.
6. Conduct penetration testing: attempt to breach controls (IDOR/BOLA, injection, auth bypass, SSRF, business-logic abuse) scoped to the level.
7. Record results per requirement: mark each verified / not verified / not applicable with supporting evidence and severity for gaps.
8. Validate and retest: confirm findings with the team, retest remediated items, and finalise the residual-risk register.
9. Report and attest: issue the ASVS verification report stating level achievement, per-domain pass rates, evidence and remediation roadmap.
10. Schedule reassessment: define triggers (major release, architecture change) and a periodic cadence for re-verification.

Evidence request list

The following categorised evidence list supports an ASVS assessment. Provide current, production-representative artefacts; screenshots and configuration exports should be dated and attributable.

Governance and design

• Secure SDLC policy and secure-coding standard
• Application inventory with assigned ASVS levels
• Data classification matrix and data inventory
• Threat models and architecture / data-flow diagrams
• Prior penetration test and assessment reports

Authentication, session and access control

• Password policy and credential-hashing implementation details
• MFA configuration and enforcement policy
• Session and cookie configuration (timeouts, flags)
• Role/permission matrix and entitlement review evidence
• Access-control test results (IDOR/BOLA, privilege escalation)

Cryptography and data protection

• Cryptographic algorithm and key-length inventory
• Key management policy and KMS/HSM/vault evidence
• Encryption-at-rest and in-transit configuration
• Data retention and secure-deletion evidence
• Privacy / DSAR handling evidence

Input handling, files and APIs

• Input validation and output encoding code samples
• SQL/command/deserialisation defence evidence
• File upload/download validation and storage configuration
• API authentication, schema validation and rate-limiting configuration
• CORS and security-header configuration

Configuration, logging and supply chain

• SBOM and SCA scan reports
• Hardening baselines (CIS) and configuration scans
• Secret scanning results and vault integration
• Security event logging design and SIEM ingestion evidence
• CI/CD access controls and artefact provenance

Roles and responsibilities

Successful ASVS adoption depends on clear ownership across engineering, security and governance. The RACI below reflects a typical operating model.

KPIs to track

• Percentage of applications with an assigned ASVS level and completed verification
• Per-domain ASVS pass rate (e.g. authentication, access control, cryptography) and trend over time
• Number of applications meeting their target level fully versus partially
• Mean time to remediate ASVS gaps by severity
• Percentage of releases passing automated ASVS pipeline gates
• Number of open critical/high ASVS findings and their ageing
• Coverage of threat modelling across L2/L3 applications
• Dependency vulnerability exposure (known-vulnerable components) and time to patch
• Percentage of high-risk flows elevated to and verified at L3
• Re-verification currency (percentage of apps re-verified within policy cadence)

Readiness checklist

• Every application has a documented, risk-based ASVS level assignment
• Data classification is complete and drives protection requirements
• Threat models exist and are current for all L2/L3 applications
• ASVS requirements are embedded in the secure-coding standard and definition of done
• Authentication uses strong credential storage, MFA and anti-brute-force controls
• Access control is server-side, least-privilege and tested for IDOR/BOLA
• Input validation, output encoding and parameterised queries are enforced
• Cryptography uses approved algorithms with managed keys and no hard-coded secrets
• All traffic uses TLS 1.2+ with HSTS and validated certificates
• Security events are logged, sensitive data masked, and forwarded to a SIEM
• Dependencies are inventoried (SBOM), scanned (SCA) and kept current
• Security headers, hardening baselines and environment segregation are in place
• CI/CD pipelines enforce ASVS gates and protect build integrity
• A verification workbook records pass/fail per requirement with evidence
• A residual-risk register with owners and timelines is maintained and approved

Common gaps

• Treating ASVS as a one-off penetration test rather than a build-time requirements baseline, so gaps recur every release
• Assigning no explicit level, leaving developers guessing how much security is 'enough'
• Client-side-only access-control enforcement, leaving IDOR/BOLA and privilege escalation exploitable server-side
• Weak or legacy credential storage (unsalted or fast hashes) and absent MFA on sensitive roles
• Hard-coded secrets and API keys committed to repositories or embedded in configuration
• Deprecated TLS/ciphers still enabled and missing HSTS or certificate validation on outbound calls
• Verbose error messages and stack traces leaking internal detail to users
• No SBOM and unmanaged third-party dependencies with known vulnerabilities
• Missing security logging or logs containing sensitive data with no SIEM forwarding
• Business-logic abuse (parameter tampering, race conditions, missing rate limits) untested by tooling and overlooked
• CORS misconfiguration (wildcard origins) and missing security headers
• Threat modelling skipped for high-risk applications, so design-level flaws go undetected

OWASP ASVS mapped to other frameworks

ASVS is complementary to governance and compliance frameworks: it provides the technical, testable application-layer controls those frameworks assume but rarely specify. The table maps ASVS to adjacent standards so a single ASVS verification can service multiple obligations.

Frequently asked questions

Need help with OWASP ASVS?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.