OWASP ASVS 5.0 Explained: Chapters, Levels and What Changed from 4.0.3

The OWASP® Application Security Verification Standard (ASVS) 5.0 replaces 4.0.3, the version in use since 2021, and it is not a light refresh: almost every requirement was rewritten, renumbered or merged. Here is what the standard is, how its 17 chapters and three levels are organized, what changed for teams that built on 4.0.3, and how I would adopt it on a real codebase.

A verification standard is a list of requirements that each end in a pass or fail verdict when someone checks an application against them. The ASVS applies that idea to web applications and services: architects use it to choose controls, developers to build them, testers to verify them and buyers to state what they expect from a supplier.

Version 5.0.0 was released live at Global AppSec EU in Barcelona on 30 May 2025, the first release since 4.0.3 in October 2021, and the project page still lists it as the latest stable release. It is published under Creative Commons Attribution-ShareAlike 4.0: you can copy and adapt it if you credit the OWASP Foundation and share adaptations under the same license.

Three scope rules from the standard's own definition explain most of its shape:

• Security only. Every requirement must demonstrably reduce the likelihood or impact of a risk. Functional, code-style and policy items are out.
• Verifiable. Every requirement is a "must" with a pass or fail result. Recommendations do not qualify.
• What, not how. Requirements state the goal. Implementation advice belongs to the OWASP Cheat Sheet Series and test procedures to the Web Security Testing Guide. The ASVS also does not prescribe a development lifecycle or a CI/CD process.

The 5.0.0 release files contain 345 requirements (the standard rounds this to "around 350") in 17 chapters, each split into sections. A requirement's identifier is chapter.section.requirement, so 6.2.4 is the fourth requirement in section 2 (Password Security) of chapter 6 (Authentication).

The ASVS chapters are meant to be filtered. A machine-to-machine API can skip the web frontend chapter, and an application without OAuth or WebRTC can skip those chapters. The five areas below are my grouping; names and counts come from the release files.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

The L columns count each requirement at the lowest level that requires it. Three things stand out. Identity and access is the largest area, with 122 requirements, more than a third of the standard. Logging (V16) and WebRTC (V17) have no Level 1 requirements at all. And 11 chapters open with a documentation section, 31 requirements in total, which is the new "documented security decisions" idea covered below.

An ASVS level is a priority tier: each requirement carries a number from 1 to 3, and levels are cumulative, so meeting Level 2 means meeting every L1 and L2 requirement. The standard describes them like this:

The standard rounds these shares to 20%, 50% and 30%. Some requirements also tighten as the level rises: v5.0.0-6.3.3 requires multi-factor authentication (or a combination of single-factor methods) from Level 2, and at Level 3 one factor must be hardware-based and resistant to phishing and impersonation.

In 4.0.3, 128 of 278 requirements (46%) were Level 1. In 5.0.0 it is 70 of 345 (20%). Feedback was that a "minimum" level of over a hundred requirements, labeled not good enough for most applications, discouraged adoption. Version 5.0 therefore builds Level 1 mainly from first-layer defenses.

The bigger change is the selection rule. In 4.x, a key reason to put a requirement in Level 1 was that an external black-box penetration test could check it. Version 5.0 calls this the fallacy of testability: a testable requirement is not necessarily easy to test, high-impact or cheap to build. Levels are now assigned by risk reduction compared with the effort to implement, while keeping the barrier to entry low.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

I counted both splits from the 4.0.3 and 5.0.0 release files; the Level 1 figures match the standard's own.

No. The standard says plainly that Level 1 is not necessarily verifiable by an outside tester without access to documentation or code. The assessment chapter adds that black-box testing was already discouraged under 4.0, and it strongly recommends documentation- or source-led (hybrid) penetration tests. It is just as direct about scanners: "testable using automation != running an off the shelf tool". DAST and SAST tools can cover some of the simpler encoding and sanitization checks, but they cannot fully verify the requirements on business logic and access control.

You do. The ASVS no longer assigns levels by application type. Each organization picks the level that fits its risk, its maturity and what its users expect. The standard's own example contrasts an early-stage startup with little sensitive data, which might start at Level 1, with a bank that would struggle to justify less than Level 3 for online banking.

ASVS 5.0 vs 4.0.3 at a glance:

• The V1 Architecture chapter. According to the changes chapter, its first section was out of scope, and the rest moved into the relevant chapters after deduplication.
• Direct CWE and NIST mappings. Some CWEs are only categories, requirements are hard to pin to a single CWE, and some 4.x mappings were imprecise. Tight alignment with NIST SP 800-63 brought unfamiliar terminology and duplicate requirements. The plan is to connect the ASVS to other standards through the OpenCRE project.
• Most of the old wording. Of the 286 requirements in 4.0.3, only 11 are unchanged and 15 got grammar-only edits. 109 (38%) are no longer separate requirements: 50 were deleted, 28 removed as duplicates and 31 merged into others. The rest were revised, and even the unchanged requirements got new identifiers because chapters were reordered.

Why two totals for 4.0.3? Its files number 286 entries, eight of them placeholders marked as deleted; the Level 1 share uses the 278 active ones.

• New content: V10 OAuth and OIDC, with sections for clients, resource servers, authorization servers, OIDC clients, OpenID providers and consent, and V17 WebRTC (TURN servers, media and signaling).
• New chapters from restructuring: V9 Self-contained Tokens (formerly part of session management), V3 Web Frontend Security (cookies, security headers, origin separation, external resource integrity) and V15 Secure Coding and Architecture (dependencies, defensive coding, safe concurrency).
• Goals over mechanisms. Requirements name a specific mechanism only when it is the sole practical solution; otherwise they state the security goal. Input validation also moved next to business logic in V2, away from encoding and sanitization.
• Documented security decisions. Rules that differ per application, such as allowed file types or session timeouts, now have explicit documentation requirements, always in the first section of a chapter and always paired with an implementation requirement. For example, v5.0.0-6.1.1 asks you to document how rate limiting and anti-automation stop credential stuffing without enabling malicious account lockout, and v5.0.0-6.3.1 asks you to implement those controls as documented. Checking the document and checking the code are two separate verifications.

The project publishes mapping files in both directions between 4.0.3 and 5.0.0. Use them to trace old findings and tests, then re-verify. The release rules explain why: a major release needs full re-evaluation, a minor release (5.1) may add or remove requirements but keeps the numbering, and a patch release (5.0.1) only removes or relaxes requirements, so compliance carries over.

Use the versioned form v<version>-<chapter>.<section>.<requirement>, with a lowercase v: v5.0.0-1.2.5 is the OS command injection requirement in 5.0.0. An unversioned ID is read as the latest version, and that goes wrong across major releases. Chapter 1 was Architecture in 4.0.3 and is Encoding and Sanitization in 5.0, so a bare "1.2.5" in a two-year-old ticket can point at a different topic depending on which version the reader assumes.

Put versioned IDs in tickets, test names, pentest scopes and supplier contracts. The 5.0.0 release ships the requirements as CSV, JSON, XML, PDF and DOCX, so you can import them into a tracker instead of copying text by hand.

Forking is actively encouraged. An organization- or domain-specific version can drop sections you never use (GraphQL, WebSockets, SOAP), add your own implementation guidance and start from Level 1. The condition is traceability: passing a requirement in your fork must mean the same as passing it in the original. If you publish the fork, the CC BY-SA license requires attribution and the same license.

Certification is a different story. The OWASP Foundation does not certify vendors, verifiers or software, and it does not endorse any trust mark claiming ASVS compliance. Third parties may offer assurance services, provided they do not claim official OWASP certification. A credible verification report states the scope and target level, lists every requirement checked (not only failures) and explains any exclusions. The accurate claim is "verified against ASVS 5.0.0 Level 2 for this scope", never "ASVS certified". For how this differs from an awareness list, see OWASP ASVS vs OWASP Top 10; for the PCI angle, see mapping ASVS to PCI DSS Requirement 6.

1. Pick a level per application, not per company. A merchant admin portal and a marketing site need different levels. Write down the reason.
2. Scope chapters and sections. Record each exclusion with a reason; a verification report needs it anyway.
3. Write the documentation requirements first. They force the decisions (password rules, authorization model, allowed file types) before anyone writes code.
4. Turn requirements into acceptance criteria and tests. An ASVS requirement states a goal; your system needs concrete rules and test scenarios that prove it.
5. Track it in the backlog. Import the CSV and keep one row per requirement: versioned ID, status (pass, fail or not applicable) and a link to the evidence.

Step 4 is where most of the work sits. On a multi-tenant payment aggregator I work on, I specified and built the admin and merchant sign-in test-first: 40 requirements and 96 test scenarios, mapped to 13 OWASP ASVS 5.0 controls. One line of the standard routinely expanded into several of our own requirements and test scenarios.

In code, I tag each test with the requirement it verifies. A minimal pytest example for a FastAPI sign-up endpoint:

# test_signup_passwords.py: `client` is a FastAPI TestClient fixture
import pytest


@pytest.mark.asvs("v5.0.0-6.2.4")
@pytest.mark.parametrize("password", ["password", "12345678"])
def test_signup_rejects_common_password(client, password):
    resp = client.post(
        "/signup", json={"email": "a@example.test", "password": password}
    )
    assert resp.status_code == 422


@pytest.mark.asvs("v5.0.0-6.2.5")
def test_signup_accepts_password_without_composition_rules(client):
    resp = client.post(
        "/signup",
        json={"email": "b@example.test", "password": "correct horse battery staple"},
    )
    assert resp.status_code == 201

Register the marker once (markers = ["asvs(id): ASVS requirement verified by this test"] under [tool.pytest.ini_options]) and the IDs become searchable evidence: grep -rF 'v5.0.0-6.2.' tests/ lists what you verify in the password section. Repeat both tests for the password change flow, which 6.2.4 covers too. I go deeper into the authentication chapter in Implementing ASVS 5.0 authentication in a payments API.

• Download the 5.0.0 CSV, delete the chapters you do not use and keep the rest as your working fork.
• Choose a level for each application and write down why.
• Fill in the documentation requirements for the chapters you kept, starting with V6 Authentication and V8 Authorization.
• Tag your existing security tests with versioned IDs; the untested requirements become backlog items.
• If you hold 4.0.3 results, re-verify through the mapping files instead of renaming IDs.

Quoted text from OWASP Application Security Verification Standard 5.0.0, © OWASP Foundation, licensed CC BY-SA 4.0. OWASP® is a registered trademark of the OWASP Foundation, Inc.; this article is independent and not endorsed by the OWASP Foundation.