The short answer
OWASP ASVS, the Application Security Verification Standard, is a free list of 345 testable security requirements for web applications and APIs, grouped into 17 chapters and three cumulative levels. Version 5.0.0, released in May 2025, is current. It is a yardstick for design, coding and testing, not a certification.
On this page
OWASP ASVS, the Application Security Verification Standard, is a free catalogue of specific, testable security requirements for web applications and APIs. Where the OWASP Top 10 names the biggest risks, the ASVS spells out what “secure” looks like, requirement by requirement, so developers can build to it and testers can verify against it.
What is OWASP ASVS?
It is a verification standard: every requirement is phrased so it can be checked and marked pass, fail or not applicable. OWASP also pitches it as an architecture guide, a secure coding reference, a source of automated tests and a procurement checklist. Requirements are numbered chapter, section, requirement, and because numbers change between releases, OWASP recommends quoting the version too, such as v5.0.0-1.2.5.
What is the current version of ASVS?
Version 5.0.0, released in May 2025, is current and holds 345 requirements in 17 chapters. The full text is on the OWASP ASVS project page.
It rewrote 4.0.3 rather than updating it. OWASP says only 11 of the 286 requirements in 4.0.3 survive unchanged, the old architecture chapter has gone, and new chapters cover web frontend security, self-contained tokens, OAuth and OIDC, and WebRTC. Old 4.0.3 IDs do not carry over; OWASP publishes mapping documents.
| Chapter | What it covers |
|---|---|
| V1 Encoding and Sanitization | Safe handling of untrusted data to prevent injection |
| V2 Validation and Business Logic | Input validation and abuse of business workflows |
| V3 Web Frontend Security | Browser-side protections such as cookie and header settings |
| V4 API and Web Service | Requirements specific to APIs and web services |
| V5 File Handling | Uploads, downloads and file storage |
| V6 Authentication | Passwords, multi-factor authentication and account recovery |
| V7 Session Management | Creating, expiring and ending sessions |
| V8 Authorization | Function and object-level access checks, where IDOR belongs |
| V9 Self-contained Tokens | Tokens such as JWTs that carry their own claims |
| V10 OAuth and OIDC | Delegated authorisation and single sign-on |
| V11 Cryptography | Algorithms, keys and random values |
| V12 Secure Communication | Encryption of data in transit |
| V13 Configuration | Secrets, build and deployment settings |
| V14 Data Protection | Handling and leakage of sensitive data |
| V15 Secure Coding and Architecture | Dependencies, safe coding patterns and design |
| V16 Security Logging and Error Handling | What to log and how to fail safely |
| V17 WebRTC | Real-time audio, video and data connections |
What are the OWASP ASVS levels?
There are three, and they are cumulative: Level 2 includes everything in Level 1, and Level 3 includes everything in Level 2.
| Level | How OWASP describes it | Usually suits |
|---|---|---|
| Level 1 | The minimum requirements, a first layer of defence (70 requirements) | Lower-risk applications, or teams new to ASVS |
| Level 2 | The level most applications should be striving to achieve | Most business applications, especially those holding personal or payment data |
| Level 3 | For applications that must demonstrate the highest levels of security | High-value systems; OWASP’s example is online banking |
OWASP asks each organisation to choose a level from its own risk analysis. One change matters for buyers: Level 1 in version 4.0 was built for black-box testing, but in 5.0 even Level 1 is not necessarily testable by an outside tester without documentation or code.
Is ASVS a certification?
No. OWASP does not certify vendors, verifiers or software, and does not endorse any certificate or trust mark claiming ASVS compliance. A credible assessment report gives the target level, the scope, a summary of every requirement checked (not just the failures), those found not applicable and the testing methods used.
Is there an OWASP ASVS checklist?
Yes, in practice the standard is the checklist. OWASP publishes ASVS 5.0.0 as CSV, JSON, XML and Word files in the OWASP ASVS GitHub repository, so you can load every requirement into a spreadsheet, ticketing system or test tool instead of copying it by hand. Each entry carries the requirement ID, its text and its level.
A tester turns that export into a working checklist by filtering it to the target level, marking chapters that do not apply, and adding columns for the result and the evidence:
| Column | What goes in it |
|---|---|
| ID | The versioned requirement number, such as v5.0.0-1.2.5 |
| Requirement | The requirement text, taken from the export |
| Level | 1, 2 or 3 |
| Applies? | Yes, or not applicable with a short reason |
| Method | Tested, code reviewed or documentation reviewed |
| Result | Pass or fail |
| Evidence | The request, screenshot, code reference or document that proves it |
Kept up to date, the same sheet doubles as the coverage record auditors and customers ask for, and as the retest list once fixes are in.
How do you use ASVS to scope a web application test or code review?
Agree in advance what will be verified and how:
- Pick a target level for each application, based on the data it holds and what a failure would cost.
- Remove what does not apply, such as the OAuth chapter if you do not use it.
- Choose the method. OWASP calls testing without documentation or code inefficient and strongly encourages hybrid testing led by documentation or source code. In practice that means pairing web application penetration testing with a secure source code review, especially at Levels 2 and 3. Automated dynamic application security testing can re-check some requirements between manual tests, but not access control or business logic.
- Write the level into contracts, for example “developed to ASVS Level 2”, and ask suppliers for evidence.
- Retest failed requirements after fixes, citing the same versioned IDs.
ASVS also supports compliance evidence. PCI DSS v4.0.1 Requirement 6.2.4 requires techniques that prevent or mitigate common attacks on bespoke and custom software, and ISO 27001:2022 lists secure coding (8.28) and security testing in development and acceptance (8.29) among its Annex A controls. Mapping your requirements to ASVS gives auditors a recognised reference.
Why Sovereign Secure?
Sovereign Secure is a PCI SSC-approved QSA company and ISO 27001 certified. We test web applications, APIs, mobile apps and cloud environments manually and review source code, using ASVS as the measure of what good looks like.
To scope a test or code review against an ASVS level, request a penetration testing quote, or browse the rest of our cyber security glossary.
Your next step
- Scope your testChoose your test types and asset counts online to scope your penetration test.Scope your test
- Pen testing cost guideUK day rates, price ranges by test type and what drives the cost.Read the cost guide
- Talk to a testerTell us what you need tested. We aim to reply within one working day.Talk to a tester
Last reviewed October 2026 by the Sovereign Secure assessment team.
