Direct answer: OWASP ASVS 5.0.0 was published on 30 May 2025 and the current stable version contains 17 chapters and 345 verifiable requirements, split by level into L1 70, L2 183 and L3 92. It is not "one more checklist"; it turns application security into verifiable clauses that can go into requirements, acceptance and contracts: every requirement has a versioned ID (such as v5.0.0-1.2.5) and can be evidenced through SAST/DAST, penetration testing, code review and configuration checks. Start by choosing the level: L1 is the baseline, L2 fits most applications with sensitive data/business, L3 is for high-value/high-assurance systems; then map the 17 chapters to the SDLC, supplier contracts and acceptance evidence instead of trying to "do all 345 at once". The main 5.0 change is a 17-chapter restructuring, with Web Frontend Security, API/Web Service, File Handling, Self-contained Tokens, OAuth/OIDC and WebRTC as dedicated chapters.
This guide is for product, engineering, QA, security, operations and procurement teams. It explains ASVS 5.0's structure, L1/L2/L3 selection, the 17 chapters, acceptance evidence, supplier clauses, common pitfalls and a 90-day adoption checklist. Data comes from the official OWASP ASVS 5.0.0 page and official CSV (published 30 May 2025, 345 requirements; accessed 8 November 2026), with reference to the OWASP ASVS project description. Official standard facts, editorial summaries and implementation advice are kept separate. This is not certification or legal advice.
(1) ASVS 5.0 is "verifiable requirements", not a penetration-test report: every item needs evidence, a test method and an exception record. (2) Do not do all 345: L1's 70 are the baseline, L2's 183 cover most sensitive applications, L3's 92 are for high-value systems; choose by risk. (3) 5.0 makes frontend, API, files, tokens, OAuth/OIDC and WebRTC dedicated chapters—if you only test the backend, you will miss a large part.
ASVS 5.0 at a glance: 17 chapters, 345 requirements, three levels
The official ASVS 5.0.0 CSV contains 345 requirements across 17 chapters; by level, L1 has 70, L2 183 and L3 92. Its purpose is to provide a basis for testing web application technical security controls, a list of secure-development requirements for developers and a procurement reference. Unlike the OWASP Top 10, which is a risk-awareness list, ASVS is a set of individually verifiable requirements. Unlike ISO 27001/SOC 2, ASVS focuses on application technical controls and does not replace an organizational management system. 5.0 also emphasizes versioned IDs (such as v5.0.0-10.4.1) so references do not drift when the standard changes.
| Item | Data | Note |
|---|---|---|
| Version | 5.0.0 | Published 30 May 2025; stable |
| Chapters | 17 | From encoding/frontend/API to OAuth/OIDC/WebRTC |
| Requirements | 345 | Official CSV can be imported into tools |
| L1 | 70 | Baseline; all applications/low risk |
| L2 | 183 | Most applications with sensitive data/business |
| L3 | 92 | High-value/high-assurance systems |
| ID format | v5.0.0-1.2.5 | Version + chapter.section.requirement for contracts/reports |
Sources: official OWASP ASVS 5.0.0 page (30 May 2025) and official CSV (345 requirements; L1/L2/L3 counts are editorial counts of the CSV L field, accessed 8 November 2026). Level definitions use ASVS's general baseline/sensitive/high-assurance split.
Choosing L1 / L2 / L3
ASVS levels are not a "score" but a depth of assurance: L1 is the minimum baseline for any application and is usually verifiable with black-box/low-intrusion methods; L2 targets most applications handling sensitive data, money, identity or business-critical flows and requires fuller defenses and evidence; L3 targets high-value/high-assurance systems (critical infrastructure, core money/identity, strong-adversary scenarios) and requires the deepest controls and verification. Choose by data sensitivity, business impact, threat model and compliance/contract requirements, not "everything L3" or "forever L1".
| Level | Fit | Verification | Common mistake |
|---|---|---|---|
| L1 | All applications/low risk/public content | Black-box, configuration checks, basic DAST | Treating L1 as "security done" |
| L2 | Sensitive data, accounts, payments, B2B core flows | Code review + DAST + pen test + evidence | Pen test only, no requirement mapping |
| L3 | High-value/high-assurance/strong adversary | Deep code/architecture review, red team/specialist testing | Full L3 everywhere, cost explosion |
| Mixed | Different modules, different levels | Grade by data flow/trust boundary | One level for the whole site |
Editorial summary, not an official certification conclusion; level selection should combine data classification, threat model and compliance/contract requirements. See the official ASVS documentation for level definitions.
Map of 17 chapters: focus and sample requirements
The 17 chapters cover the main modern web/API attack surface. Below are each chapter's requirement count, L1/L2/L3 split and one sample requirement (Chinese/English summaries are editorial paraphrases; exact wording follows ASVS 5.0). Authentication (47), OAuth/OIDC (36), Web Frontend Security (31) and Encoding (30) are the densest chapters; WebRTC and Self-contained Tokens show ASVS now covers real-time communication and token architectures.
| Chapter | Requirements | L1/L2/L3 | Sample requirement (paraphrase) |
|---|---|---|---|
| V1 Encoding and Sanitization | 30 | 8/19/3 | Contextual output encoding for HTML/attributes/CSS/HTTP headers |
| V2 Validation and Business Logic | 13 | 4/7/2 | Document input-validation rules and expected structure |
| V3 Web Frontend Security | 31 | 8/11/12 | Prevent browsers from rendering content in the wrong context |
| V4 API and Web Service | 16 | 2/8/6 | Content-Type matches response body/charset |
| V5 File Handling | 13 | 4/5/4 | Limit file size to avoid DoS/performance loss |
| V6 Authentication | 47 | 13/22/12 | Document rate limiting/anti-automation/adaptive response |
| V7 Session Management | 19 | 6/12/1 | Session tokens verified by a trusted backend |
| V8 Authorization | 13 | 4/3/6 | Document function-level/data-specific authorization rules |
| V9 Self-contained Tokens | 7 | 4/3/0 | Verify token integrity with signature/MAC |
| V10 OAuth and OIDC | 36 | 5/24/7 | Exact client-specific redirect URI allowlist matching |
| V11 Cryptography | 24 | 3/11/10 | No ECB/weak padding and other insecure modes |
| V12 Secure Communication | 12 | 3/6/3 | Only recommended TLS 1.2/1.3 enabled |
| V13 Configuration | 21 | 1/12/8 | Do not expose .git/.svn source metadata |
| V14 Data Protection | 13 | 2/7/4 | Sensitive data only in body/header, not URL/query |
| V15 Secure Coding and Architecture | 21 | 3/10/8 | Risk-based remediation timeframes for vulnerable components |
| V16 Security Logging and Error Handling | 17 | 0/16/1 | Logging inventory (layers/events/format/storage/access) |
| V17 WebRTC | 12 | 0/7/5 | TURN only allows non-reserved/non-internal IPs |
Sources: official OWASP ASVS 5.0.0 CSV (accessed 8 November 2026); samples are editorial paraphrases, exact wording follows the ASVS 5.0 text/CSV. L1/L2/L3 counts are from the CSV L field.
Acceptance: one requirement = one evidence item
ASVS's value is verifiability, so every requirement needs evidence: code/configuration/architecture documents, automated test results, SAST/DAST reports, penetration-test records, manual review conclusions, screenshots/logs and exception approvals. Put ASVS IDs directly into user-story acceptance criteria, test cases and supplier contracts; record not-applicable items with a reason and compensating control rather than "skip". Acceptance can be sampled/full by level: L1 is mostly automatable, L2 combines code review and pen testing, L3 needs deep review/red teaming.
| Step | Action | Output |
|---|---|---|
| Scope | Choose L1/L2/L3 by data flow/trust boundary | Scope statement, level matrix |
| Map | Map ASVS IDs to requirements/architecture/tests | Requirement-control matrix |
| Evidence | SAST/DAST/code review/pen test/config checks | Per-requirement evidence pack |
| Exceptions | Not-applicable/risk acceptance needs reason + compensating control | Exception register, approval |
| Acceptance | Sample/full review by level | Acceptance report, open items |
| Contract | Reference version + level + evidence | Supplier clauses/SLA |
Editorial acceptance workflow, not an official certification process; ASVS is a requirements standard and does not issue certifications. Test methods/evidence strength follow organizational risk.
Common mistakes: why "we did ASVS" is still insecure
The most common mistakes: treating ASVS as a penetration-test checklist (testing without building), testing only the backend and ignoring frontend/API/OAuth chapters, forcing L3 everywhere, using unversioned IDs so reports do not align, treating "not applicable" as "pass", suppliers claiming "ASVS compliant" without per-requirement evidence, and treating ASVS as a compliance certificate (it is not ISO/SOC). Another frequent issue is failing to update mappings after a standard upgrade: 5.0's chapters/IDs differ from 4.0.3, so old reports cannot simply be reused.
| Mistake | Impact | Correction |
|---|---|---|
| Pen test only | Incomplete coverage, no per-requirement acceptance | Evidence across requirements/design/code/test |
| Backend only | Miss frontend/API/OAuth/WebRTC | Cover all 17 chapters |
| Full L3 | High cost, unclear priorities | Grade by data/boundary |
| No versioned IDs | Reports drift from the standard | Reference v5.0.0-x.y.z |
| Not applicable = pass | Hides risk | Record reason + compensating control |
| Supplier verbal compliance | Unverifiable | Contract requires per-item evidence |
| Treat as certificate | Misleading management/customers | Explain ASVS is a requirements standard |
Editorial common-issue list, not an official checklist; acceptance/audit requirements follow organizational policy, contracts and applicable regulation.
90-day adoption checklist
Use the first 90 days to close the loop on "level, mapping, pilot, evidence, contract": weeks 1-2 set scope and levels; weeks 2-4 map the 17 chapters to existing requirements/tests; weeks 4-6 run a pilot on one L2 application; weeks 6-8 fill evidence/fix gaps; weeks 8-10 put ASVS into supplier contracts/acceptance templates; weeks 10-12 review and scale. Do not try "all 345" in week one, and do not declare completion after buying a scanner.
| Phase | Action | Output |
|---|---|---|
| Weeks 1-2 | Choose L1/L2/L3 by data/business/threat; define scope | Level matrix, scope statement |
| Weeks 2-4 | Map 17 chapters to requirements/architecture/tests/existing controls | Control matrix, gap list |
| Weeks 4-6 | Pilot one L2 application; collect per-requirement evidence | Pilot evidence pack, issue list |
| Weeks 6-8 | Fix high priorities; add tests/code review | Remediation log, retest |
| Weeks 8-10 | Reference ASVS version+level in supplier contracts/acceptance templates | Contract clauses, acceptance template |
| Weeks 10-12 | Review and scale to more applications/teams | Scale plan, training |
Editorial adoption advice, not an official template; scope, level, testing and contract requirements follow organizational risk/policy.
FAQ
When was ASVS 5.0 released?
ASVS 5.0.0 was published on 30 May 2025 and is the current stable version; the official site provides PDF, DOCX and CSV downloads, and the CSV contains 345 requirements.
Do we have to implement all 345 requirements?
No. Choose by level: L1's 70 are the baseline, L2's 183 cover most sensitive applications and L3's 92 are for high-value/high-assurance systems; then use mixed levels by module/trust boundary.
How do we choose L1/L2/L3?
By data sensitivity, business impact, threat model and compliance/contract requirements. L1 for all applications; L2 for sensitive data/money/identity/core flows; L3 for high-value/strong-adversary/critical systems. Do not force all L3 or stay at L1 forever.
What is the difference between ASVS and the OWASP Top 10?
The Top 10 is risk awareness and categorization; ASVS is verifiable technical requirements. The Top 10 helps prioritize; ASVS helps write requirements, acceptance and evidence.
How does ASVS relate to PCI DSS/SOC 2?
ASVS focuses on application technical controls and can complement/map to the technical layer of PCI DSS/SOC 2/ISO 27001, but it is not a certificate; compliance conclusions come from the relevant audit/certification scheme.
How do we prove "ASVS compliance"?
Per-requirement evidence: code/configuration/architecture documents, SAST/DAST, penetration tests, manual review, screenshots/logs; not-applicable items need a reason and compensating control. Supplier contracts should reference the exact version+level+evidence.
What changed from 4.0.3 to 5.0?
5.0 restructures into 17 chapters and 345 requirements, with Web Frontend Security, API/Web Service, File Handling, Self-contained Tokens, OAuth/OIDC and WebRTC as dedicated chapters; use versioned IDs (such as v5.0.0-10.4.1), and do not reuse old reports unchanged.
Can ASVS replace penetration testing?
No. ASVS is a requirements/acceptance framework; penetration testing is one evidence method. They complement each other. L2/L3 usually need code review + DAST + pen test + architecture review.
Research method and limitations
This article separates "official standard facts" from "editorial summaries." The ASVS 5.0.0 publication date, 17 chapters, 345 requirements, L1/L2/L3 counts, ID format and CSV/PDF downloads come from the official OWASP ASVS 5.0.0 page and official CSV (published 30 May 2025, accessed 8 November 2026); chapter samples are editorial paraphrases of the CSV req_description. Level fit, acceptance workflow, pitfalls and the 90-day checklist are editorial. OWASP ASVS is an open standard and does not issue certifications; testing/audit requirements follow organizational policy and contracts.
Eight limitations: (1) this is not certification/legal advice; (2) it covers web application/service technical controls, not the full organizational/physical/supply-chain system; (3) all 345 requirements are not translated individually; (4) specific tool/scanner ASVS coverage is not assessed; (5) no real application pilot/penetration test is included; (6) clients beyond web/API are not covered; (7) level selection depends on the organizational risk model; (8) the standard may update, so lock v5.0.0 and recheck the official page when citing.
Sources and basis
- OWASP, Application Security Verification Standard 5.0.0 (30 May 2025): owasp.org/www-project-application-security-verification-standard. Version, downloads, ID format, purpose. Accessed 8 November 2026.
- OWASP ASVS 5.0.0 official CSV: github.com/OWASP/ASVS/.../ASVS_5.0.0_en.csv. 345 requirements, chapters, L field. Accessed 8 November 2026.
- OWASP ASVS 5.0.0 official PDF: github.com/OWASP/ASVS/.../ASVS_5.0.0_en.pdf. Full standard text. Accessed 8 November 2026.
- OWASP ASVS project repository: github.com/OWASP/ASVS. Versions/releases/translations/tools. Accessed 8 November 2026.
Data cut-off 8 November 2026; ASVS clauses follow the v5.0.0 official text/CSV; this is not certification, legal or procurement advice.