OWASP ASVS
Application Security Verification Standard at L1, L2, and L3
The OWASP Application Security Verification Standard (ASVS) is the open standard that defines what a verified secure web application looks like, requirement by requirement. Pick a verification level (L1 opportunistic, L2 standard, L3 advanced), test against the named requirements, and produce a verification report that maps findings to ASVS rather than to a generic vulnerability list. SecPortal runs ASVS engagements as structured records with requirement-level traceability from kickoff to verified close.
No credit card required. Free plan available forever.
OWASP ASVS: a verification standard, not just another vulnerability list
The OWASP Application Security Verification Standard (ASVS) is the open standard that defines what a verified secure web application looks like, requirement by requirement. Where the OWASP Top 10 ranks the most critical risks, ASVS describes what controls have to be in place and what tests have to pass for an application to be considered verified at a given level. ASVS is published by the Open Worldwide Application Security Project, is freely available under a Creative Commons licence, and is the underlying standard that CREST OVS, many regulated procurement frameworks, and several national assurance schemes refer to when they require an application security claim that goes beyond a finding list.
ASVS is most useful when buyers and consultancies want comparability across providers and a precise definition of depth. A pentest report that lists ten findings is not directly comparable to a different pentest report that lists eight findings: the scope, the depth, the methodology, and the requirement coverage may all differ. An ASVS verification at Level 2 against a named set of requirements is comparable, because the requirements are the same document for every provider. The OWASP Top 10 framework reference covers the headline risk taxonomy; this page covers the verification standard that sits underneath it.
ASVS verification levels: pick the level on purpose
ASVS defines three verification levels. The level is a contractual decision: a Level 1 engagement reported as Level 3 is a scope breach, and a Level 3 engagement reported as Level 1 is a value gap. Decide the level during pre-engagement, name it in the rules of engagement, and reflect it on every page of the verification report.
Level 1 (opportunistic)
Defends against attackers using common, low-effort techniques. Suited to applications with limited sensitive data exposure and no regulated requirement for deeper assurance. ASVS Level 1 is verifiable mostly through automated and lightly augmented testing, which makes it a useful floor rather than a meaningful claim of secure design. A Level 1 verification report names the requirements in scope and any deviations, and is honest about what was not exercised.
Level 2 (standard)
Defends against the majority of risks for applications that handle business-critical or sensitive information. Level 2 is the default level for most commercial verification engagements, and the level CREST OVS engagements default to. It requires evidence-based testing of access control, authentication, session management, input validation, cryptography, and business logic, mapped requirement by requirement to ASVS rather than to a generic vulnerability list.
Level 3 (advanced)
Defends against advanced attackers and is appropriate for applications handling life-critical, safety-critical, or large volumes of regulated data. Level 3 requires substantially deeper testing and evidence, including code review where in scope, formal threat modelling, and a verification report that justifies the level claim against the OWASP requirement set. Level 3 is rare in commercial scopes; treat it as a deliberate choice, not a default.
For a longer treatment of the engagement scaffolding (rules of engagement, scope, authorisation, retest mechanics) that supports an ASVS verification, see the pentest rules of engagement template and the pentest scoping calculator, which produces a defensible day estimate aligned to PTES and OWASP WSTG depth levels.
The ASVS chapter set: what gets verified
ASVS is organised into 14 chapters covering architecture and design through to deployment configuration. Every chapter contains numbered requirements with explicit applicability for Level 1, Level 2, and Level 3. The verification report references those requirement numbers directly, which is what makes ASVS engagements comparable across providers.
V1: Architecture, Design, and Threat Modelling
The shape of the application security claim. Documented architecture, threat modelling artefacts, and security design records. A Level 2 or Level 3 ASVS claim without a documented threat model is not a defensible engagement; V1 is where the verification gets its anchor.
V2: Authentication
Password storage and complexity, credential recovery, lookup secrets, out-of-band authenticators, multi-factor authentication, and session binding. V2 distinguishes minimum-viable auth at L1 from phishing-resistant MFA at L3.
V3: Session Management
Session token generation, transmission, idle and absolute timeouts, re-authentication for sensitive actions, cookie attributes, and concurrent session handling. V3 closes the loop on V2: weak sessions are how authentication issues become exploitable.
V4: Access Control
Authorisation enforcement on every request, least privilege, validation of direct object references, and horizontal and vertical privilege escalation defences. V4 maps directly to OWASP Top 10 A01 Broken Access Control and is where most authenticated DAST findings cluster.
V5: Validation, Sanitisation, and Encoding
Input validation, output encoding, parameterised queries, file upload validation, SSRF protection, deserialisation safety, and template injection defences. V5 is the broad surface that catches injection and cross-site scripting findings.
V6: Stored Cryptography
Cryptographic algorithm selection, key management, randomness, secret storage, and salt and pepper handling. V6 anchors PCI DSS, HIPAA, and GDPR technical evidence when the test is an ASVS engagement.
V7: Error Handling and Logging
Error message handling, log content, and the line between useful diagnostics and information disclosure. V7 also covers what is logged for security events and how those logs are retained, which is the bridge to V11 business logic and detection.
V8: Data Protection
Protection, retention, and destruction of regulated data; client-side storage rules; cache control. V8 is the chapter most often referenced when a privacy or data protection regulator asks for technical evidence.
V9: Communications
TLS settings, HSTS, certificate handling, and HTTP security header expectations. V9 sits next to V14 (configuration) for any honest claim that transport and configuration are secure together rather than separately.
V10: Malicious Code
Defences against malicious code injection, supply chain risk, unsigned updates, and unauthorised code execution. V10 has grown in importance as supply chain attacks moved from theoretical to routine.
V11: Business Logic
Replay, sequence, race conditions, and authorisation bypass through the business workflow rather than the technical layer. V11 is where mature engagements spend disproportionate effort because business logic flaws are not catchable by automated tooling alone.
V12: Files and Resources
File upload, storage, retrieval, and execution paths. V12 is the chapter that catches the unrestricted file upload findings that surface again and again in pentest reports.
V13: API and Web Service
REST, GraphQL, SOAP, and WebSocket security including authentication, authorisation, schema validation, rate limiting, and CORS. V13 is where API-led applications spend most of their verification budget.
V14: Configuration
Build pipeline, deployment configuration, dependency management, and security header configuration. V14 is the chapter that ties verification back to operations: a Level 2 or Level 3 claim that does not exercise V14 is not a deployable application claim.
The chapter set is broad on purpose. A verification claim that exercises only V2 and V4 is a partial verification, not a full ASVS engagement at the declared level. When scoping an ASVS test, write down the chapters in scope and the chapters explicitly out of scope, so the report cannot be read as a stronger claim than was tested. For deeper context on how web app testing maps to scanner output, see the web application testing use case and the matching web application penetration testing checklist.
ASVS reporting expectations: the deliverable, not an export
An ASVS verification report is a structured deliverable, not a wrap-up. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and evidence density determine whether the verification was actually useful.
- Verification level claim (Level 1, Level 2, or Level 3) declared up front, with the reason the level was chosen rather than a higher or lower one
- In-scope ASVS requirements listed by chapter and requirement number, with explicit deviations documented for any requirement that was excluded with a reason
- Out-of-scope items declared explicitly so the report cannot be read as a stronger claim than was tested (the asset list, the testing window, and the authentication context all belong here)
- Findings logged against the requirement they evidence, with the ASVS requirement number, the OWASP Top 10 category where applicable, the CWE identifier, and a CVSS 3.1 vector for severity
- Evidence inline with each finding: request, response, screenshot, payload, or proof-of-concept retained on the same record so a reviewer can validate the result without asking for the working file
- Remediation guidance written for the engineering audience that will fix the finding, citing the ASVS requirement and the upstream control rather than restating the vulnerability description
- Retest scope agreed at kickoff (the retest count, the retest window, and the verification method per finding) so the verification report can include verified-fixed status without renegotiation
- Closure record covering the original finding, the proposed fix, the retest evidence, and the final outcome, so the verification claim is a record rather than a pdf attached to an email
For deeper context on how to structure a pentest report end to end, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the executive summary, technical body, and remediation roadmap from the underlying engagement, findings, and verification level claim, citing the ASVS requirements that were exercised rather than starting from a blank template.
How ASVS sits next to OWASP Top 10, WSTG, CREST OVS, and MASVS
ASVS is rarely used in isolation. It is the requirement set that other documents cite, run against, or wrap. The contrast below is a working view, not a buyer comparison: the practitioner question is which standards to pair ASVS with, not which to pick instead of it.
ASVS vs OWASP Top 10
The OWASP Top 10 is a ranked list of the most critical risks to web applications. ASVS is a verification standard that says, requirement by requirement, what a verified secure application looks like. The two compose: ASVS V4 maps to Top 10 A01, ASVS V3 and V7 map to A07, and so on. A pentest scoped to the Top 10 covers the headline risks. An ASVS engagement covers the requirement set and produces a verification report rather than a finding list.
ASVS vs OWASP WSTG
The OWASP Web Security Testing Guide (WSTG) is a how-to document covering testing techniques. ASVS is what the application is being tested against. WSTG describes how to test for SQL injection; ASVS says which requirement is verified when the test passes. Most mature engagements pair WSTG (the technique reference) with ASVS (the requirement set) and CVSS (the severity language).
ASVS vs CREST OVS
CREST OVS is the accreditation wrapper around ASVS. OVS engagements declare the ASVS verification level, name the requirements in scope, and produce a report that maps findings to ASVS. CREST adds the firm-level and individual-level accreditation that backs the verification claim. ASVS is the standard; OVS is the credential and the report convention applied on top.
ASVS vs MASVS
OWASP MASVS is the mobile equivalent of ASVS. The two share the same level structure (L1, L2, L3) and the same engagement shape, but MASVS adds chapters specific to mobile platforms (cryptography on device, platform interaction, code quality and binary protection). Engagements that cover both web and mobile in one scope typically declare an ASVS level for the web tier and a MASVS level for the mobile tier separately.
Buyers procuring a CREST aligned web application engagement should look at CREST penetration testing, which is the accreditation wrapper that operationalises ASVS through the OVS scheme. Buyers needing a methodology citation under a regulated procurement framework should pair ASVS with PTES as the engagement-level methodology, and with ISO 27001 Annex A.8.8 (technical vulnerability management) when the verification feeds an ISMS audit. Buyers procuring a verification for the mobile tier of the same product should pair ASVS with OWASP MASVS, which applies the same level structure to iOS and Android applications and adds mobile-specific control groups for storage, platform interaction, and binary resilience.
ASVS for AppSec teams, pentest firms, and DevSecOps programmes
ASVS is read differently depending on which side of the engagement you sit on. AppSec teams use ASVS as the internal bar that engineering builds against, and as the structure that triages findings from authenticated DAST, SAST, and SCA into one comparable picture. Pentest firms use ASVS as the standard their report is written against, and as the language that lets clients compare engagements over time. DevSecOps programmes use ASVS as the gate their CI/CD pipeline is calibrated against, especially V14 (configuration) and V13 (API and web service).
The persona-specific entry points are SecPortal for application security teams, SecPortal for cybersecurity firms, and SecPortal for DevSecOps teams. Each anchors a different view of the same ASVS engagement record.
Where SecPortal fits in an ASVS verification engagement
SecPortal is the operating layer for an ASVS verification engagement. The platform handles scope, level claim, requirement coverage, authenticated DAST evidence, finding triage, retests, and the final deliverable so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running ASVS or OVS engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals.
- Engagement management captures the ASVS verification level, the in-scope chapters and requirements, the rules of engagement, the testing window, and the agreed retest scope as a structured record so the engagement scaffold is the workflow rather than a contract attachment
- Findings management stores each finding with a CVSS 3.1 vector, severity, evidence, owner, OWASP Top 10 category, CWE identifier, and a free-text mapping field for the ASVS requirement being verified, so the verification report writes itself from the underlying records
- Authenticated scanning runs DAST modules behind the login screen against the same engagement record, with credentials stored encrypted at rest under AES-256-GCM (cookie, bearer, basic, or form-login), so V2, V3, V4, and V13 evidence is reproducible across retest cycles
- External scanning produces V9 and V14 evidence (TLS configuration, HTTP security headers, and exposed services) on a schedule, attached to the same engagement so transport and configuration claims are not re-tested manually for every report
- AI-assisted reports compose the executive summary, technical body, and remediation roadmap from the live engagement, findings, and verification level claim, citing the ASVS requirements that were exercised rather than starting from a blank template
- Client portal delivers the verification on the consultancy subdomain so the buyer sees the live engagement, retests, and closure status rather than a frozen PDF, with branded styling that matches OVS member firm reporting expectations
- Compliance tracking lets one ASVS engagement satisfy framework mappings to ISO 27001 Annex A.8.8, SOC 2 Trust Services Criteria, PCI DSS Requirement 6, and CREST OVS without rebuilding the bundle for each audit
Looking for the engagement workflow itself, end to end? The penetration testing use case and the pentest project management use case capture how SecPortal turns an ASVS-shaped engagement into a structured record covering scope, level claim, findings, retests, and the deliverable. For the retest mechanics specifically, see the pentest retesting use case.
For procurement-side context (how buyers should compare ASVS aligned proposals on effective day rate, requirement coverage, retest policy, and reporting depth), see the pentest pricing models research and the pentest scope creep research, which together cover the contract structure that holds an ASVS verification claim together over time.
Key control areas
SecPortal helps you track and manage compliance across these domains.
V1: Architecture, Design, and Threat Modelling
Verify that the application has a documented architecture, that threat modelling has been performed, and that the security controls in place are appropriate for the data sensitivity and the threat actors in scope. ASVS V1 requirements anchor the rest of the verification: a Level 2 or Level 3 claim without a documented threat model is not a defensible ASVS engagement.
V2: Authentication
Verify password storage (hashing algorithm, salt, work factor), credential recovery, lookup secrets, out-of-band authenticators, multi-factor authentication, and session binding. V2 is the most cited chapter in ASVS engagements because authentication is the surface most engagements stress test first; the requirements distinguish minimum-viable auth (L1) from phishing-resistant MFA (L3).
V3: Session Management
Verify session token generation, transmission, expiry, idle timeout, absolute timeout, re-authentication for sensitive actions, cookie attributes (Secure, HttpOnly, SameSite), and concurrent session handling. V3 sits next to V2 in nearly every report because session weaknesses are how authentication issues become exploitable.
V4: Access Control
Verify that the application enforces access control on every request, that least privilege is applied, that direct object references are validated, and that horizontal and vertical privilege escalation paths are tested. V4 maps directly to OWASP Top 10 A01 (Broken Access Control) and is where the majority of authenticated DAST findings cluster.
V5: Validation, Sanitisation, and Encoding
Verify input validation, output encoding (HTML, JavaScript, URL, CSS), parameterised queries, file upload validation, SSRF protection, deserialisation safety, and template injection defences. V5 covers the broad surface that catches injection and cross-site scripting findings, and the requirements get progressively stricter from L1 (validation present) to L3 (provably safe).
V6, V7, V8: Cryptography, Error Handling, Data Protection
Verify cryptographic algorithms, key management, randomness, secret storage, and TLS configuration (V6); error message handling, log content, and sensitive data exposure in errors (V7); and the protection, retention, and destruction of regulated data (V8). These chapters underwrite GDPR, HIPAA, and PCI DSS technical control evidence when ASVS is used as the testing standard.
V9, V10, V11: Communications, Malicious Code, Business Logic
Verify TLS settings, HSTS, certificate handling, and HTTP security headers (V9); guard against malicious code injection, supply chain risk, and unsigned updates (V10); and verify business logic flows for replay, sequence, race conditions, and authorisation bypass (V11). V11 is increasingly important as APIs and complex stateful workflows expand the business logic attack surface.
V12, V13, V14: File Handling, API and Web Service, Configuration
Verify file upload, storage, retrieval, and execution paths (V12); REST, GraphQL, SOAP, and WebSocket security including authentication, authorisation, schema validation, and rate limiting (V13); and configuration of the deployment environment, build pipeline, and security headers (V14). V13 is where API-led applications spend most of their ASVS verification budget.
Run ASVS verification with requirement-level traceability
Pick the level, test the named requirements, and ship a verification report mapped to ASVS rather than a generic finding list. Start free.
No credit card required. Free plan available forever.