The Standard That Actually Defines Secure Web Applications — OWASP ASVS 5.0

The web application security space is full of lists — Top 10s, checklists, vendor frameworks, scanner reports. What it has often lacked is a single authoritative document that answers the harder question: what does a genuinely secure web application actually have to do?

The OWASP Application Security Verification Standard is the answer to that question. Version 5.0 was released in May 2025, and it's a substantial rework — not a cosmetic update. This article walks through what the standard is, how its three levels work, and how teams actually put it to use.

What Problem Does ASVS Solve?

Security guidance typically comes in two forms: lists of things that go wrong (OWASP Top 10, CVEs, pentest findings) or vendor-specific implementation docs ("here's how to configure our WAF"). Both are useful, but neither tells you whether your application is secure in a comprehensive, verifiable way.

ASVS occupies different ground. It defines security as a set of verifiable requirements — things an application must do — rather than a set of vulnerabilities to avoid. The goal is to give architects, developers, testers, and buyers a shared language for what "secure" means, grounded in outcomes rather than tools or processes.

That scope boundary is deliberate. ASVS covers the software product itself: the code, its configuration, and the components (WAFs, load balancers, proxies) that enforce or depend on application-level controls. It explicitly does not cover CI/CD pipelines, DNS management, backup processes, or infrastructure concerns that sit outside the application's control. It also deliberately avoids overlapping with other OWASP projects — implementation guidance belongs to the Cheat Sheet Series; testing procedures belong to the Web Security Testing Guide.

Every requirement in ASVS has to meet a tight definition: it must have a demonstrable impact on security, and it must be verifiable with a binary pass/fail outcome. If a control can't be verified, it's not in the standard.

Why ASVS Needed a Version 5

Version 4.0 was published in 2019, with a minor patch (v4.0.3) in 2021. A lot changed in the intervening years: OAuth 2.0 and OIDC became the dominant patterns for access delegation and identity federation, WebRTC matured into a widely deployed technology, and the state of cryptographic best practice evolved significantly with the NIST post-quantum standards.

But the structural issues in v4 were arguably more pressing than the missing content.

The Level 1 problem. Version 4 had 128 requirements at Level 1 — 46% of the total. That's a steep entry ramp, and the designation of Level 1 as "minimum" discouraged adoption because teams read it as "not good enough for most applications." In practice, many teams either ignored the standard or never got past Level 1.

The testability fallacy. Level 1 in v4 was designed around what could be assessed through black-box external penetration testing. The intent was accessibility, but the result was a level whose composition was shaped by what's easy to probe rather than what provides the most security value. Black-box testing is an inefficient and incomplete verification mechanism regardless — it misses source-code-level issues, can't validate documented decisions, and can't test business logic thoroughly.

Requirements prescribing mechanisms, not goals. Many v4 requirements specified a particular technical mechanism rather than the security objective. This created unnecessary rigidity: if a team had a different but equally valid way to achieve the same goal, the requirement worked against them rather than for them.

Version 5.0 addresses each of these directly.

What Changed in Version 5.0

Of the 286 requirements in v4.0.3, only 11 remain unchanged in 5.0. That's not a typo. 50 requirements were deleted entirely, 28 removed as duplicates, and 31 merged into other requirements. The rest were revised. Even requirements that weren't substantively changed have different identifiers because of structural reorganization.

The headline changes in philosophy:

Security goals over mechanisms. Requirements now describe what must be achieved. A specific mechanism is only referenced when it's the sole practical solution, or when it's offered as an example. This gives organizations flexibility to meet the requirement in ways that fit their stack and context.

Documented security decisions as first-class requirements. This is one of the more significant structural additions. For controls where the right answer is inherently application-specific — what file types are permitted, what the session timeout policy is, what password rules apply — ASVS 5.0 introduces explicit documentation requirements. Before you can verify that a control is implemented correctly, you need to know what "correctly" means for that application. Documentation requirements make that explicit and auditable.

These are always placed in the first section of a chapter and are tied to corresponding implementation requirements. Verifying that the documentation exists and verifying that the implementation matches it are treated as two separate activities.

Tighter scope. Requirements that didn't meet the scope criteria — no demonstrable security impact, not verifiable, or outside the application boundary — were removed.

Structural additions. The standard grew from around 280 requirements to approximately 350, across 17 chapters. New chapters cover OAuth and OIDC, WebRTC, Self-Contained Tokens, Web Frontend Security, and Secure Coding and Architecture. The former V1 Architecture chapter was removed; its content was either out of scope or redistributed to relevant chapters.

No more direct CWE or NIST mappings. Both were removed from the main body of the standard. The CWE mappings in v4 were imprecise, and the tight alignment with NIST SP 800-63 terminology made some chapters harder to follow. Future cross-referencing will go through the OWASP Common Requirement Enumeration (CRE) project instead.

The Three Verification Levels

ASVS 5.0 retains the three-tier model from v4, but with substantially different level definitions. The levels are cumulative — Level 2 requires everything in Level 1 plus the Level 2 requirements, and Level 3 requires all of it.

Level 1 — The Starting Point (~20% of requirements)

Level 1 contains roughly 70 requirements. The design principle is: as few requirements as possible, focused on first-layer defenses against attacks that don't require other vulnerabilities or preconditions to be exploitable.

Think of the basics: parameterized queries to prevent SQL injection, output encoding in the right context, secure cookie attributes, password hashing with a modern KDF, rate limiting on authentication endpoints. These controls either directly block a class of attack, or their absence makes an application obviously vulnerable.

Password-specific requirements are weighted toward Level 1 because from Level 2 onward, MFA requirements come into play, which changes the threat model.

Level 1 is a reasonable baseline for an early-stage product or a low-sensitivity application. A startup collecting limited non-sensitive data can reasonably start here. An application processing health data or financial transactions has no business staying at Level 1 for long.

Level 2 — Standard Security Practice (~70% of requirements total)

Level 2 is where most applications should be aiming. An application that meets Level 2 has implemented around 70% of all ASVS requirements (all L1 plus all L2).

The Level 2 requirements address less common attacks, more complex protections against common attacks, and controls that require preconditions before they become exploitable. Multi-factor authentication is mandatory from Level 2 onward. Content Security Policy with at minimum object-src 'none' and base-uri 'none' is required. HTTPS enforcement, breached password checking, WebSocket origin validation, and CORS configuration all land at this level.

An e-commerce platform, a healthcare portal, an HR system — applications like these should be at Level 2 as a baseline.

Level 3 — Advanced and High-Assurance (~30% of requirements)

Level 3 adds the final layer: defense-in-depth mechanisms and controls that are genuinely hard to implement but provide meaningful additional assurance for the applications that justify the investment.

Hardware-backed, phishing-resistant authentication (FIDO hardware keys, mobile devices with a trusted execution environment) is required at Level 3. Email is explicitly prohibited as an authentication factor. OAuth authorization servers must use Pushed Authorization Requests for all code grants and must require sender-constrained access tokens. Cryptography must use constant-time comparisons throughout. Per-response CSP using nonces or hashes replaces blanket policies. HSM-backed secrets storage is required.

Level 3 is for applications where compromise would be severe: banking, critical infrastructure, government services, healthcare systems that handle sensitive clinical data.

Choosing Your Level

ASVS 5.0 is explicit that levels are not prescriptively assigned based on industry or data type. Organizations are expected to analyze their own risk and decide. The standard offers guidance by example: a startup with limited sensitive data may reasonably target Level 1 initially; a bank would have difficulty justifying anything less than Level 3 for an online banking application.

The priority-based level allocation holds for the vast majority of cases, but organizations can and should prioritize requirements from higher levels earlier if their specific risk profile warrants it.

How Teams Actually Use ASVS

The ASVS is most commonly thought of as a compliance checklist for security assessments — and it is that, but that's a narrow use of it. The standard identifies several distinct practical applications.

Security Requirements Baseline

The most direct use: take the ASVS level appropriate to your application and use it as your security requirements document. Requirements are structured as <chapter>.<section>.<requirement> — for example, v5.0.0-6.2.1 identifies a specific password security requirement in version 5.0.0. This numbering makes ASVS requirements directly referenceable in tickets, design documents, and acceptance criteria.

For organization-specific use, the standard actively encourages forking: create a tailored version that strips out chapters irrelevant to your stack (no WebRTC chapter if you don't operate WebRTC infrastructure; no GraphQL section if you don't have a GraphQL API) and adds your organization's specific implementation guidance — which libraries to use, which internal APIs satisfy which requirements. The requirement identifiers should remain traceable to the upstream standard.

Procurement and Third-Party Evaluation

Buyers of software or development services can specify a required ASVS level contractually and ask vendors to demonstrate compliance. This is clean because ASVS is technology-agnostic and vendor-neutral. Rather than writing bespoke security requirements for every procurement, you reference the standard and specify a level.

OWASP does not certify vendors or software. Any claim of "ASVS certified" from a third party isn't officially endorsed — organizations can offer assurance services against ASVS, but there's no OWASP seal of approval to buy.

Security Architecture Guidance

The documentation requirements and architecture-level requirements in ASVS make it a useful resource for security architects working through design decisions. The authentication chapter, the authorization chapter, and the OAuth/OIDC chapter in particular are detailed enough to guide implementation choices — not just evaluate them.

Automated Testing Baseline

ASVS is designed to be testable. Technical requirements can form the basis for automated unit and integration tests. For a login controller, that might mean tests covering account enumeration via differential error responses, brute-force defenses, LDAP injection, and null byte injection in password fields. These tests can be integrated into CI pipelines and run on every build.

Automation has limits. DAST and SAST tools can catch some basic requirements, but they cannot fully verify access control logic, business logic flows, or documentation requirements. Automated testing helps with continuous verification of technical controls; it doesn't replace human review for the more complex requirements.

Developer Security Training

Because ASVS is organized around security goals rather than vulnerability classes, it's structurally better suited to developer education than, say, the OWASP Top 10. The Top 10 is a list of things that go wrong. ASVS is a description of how things should work. Training built around ASVS teaches developers to build secure software rather than just avoid the most common mistakes.

The Structure of ASVS 5.0: What's Covered

The 17 chapters in ASVS 5.0 cover the following areas:

This series will go through each of these in turn. Encoding and sanitization comes first — it covers the most prevalent class of web vulnerabilities and sets up the concepts that recur across other chapters.