OWASP ASVS: Application Security Requirements

OWASP ASVS

"Is our application secure?" has no useful answer. "Does our application meet these specific, testable security requirements, at this level, with this evidence?" does. The OWASP Application Security Verification Standard (ASVS) provides those requirements: a structured catalog of security controls for web applications and APIs — authentication, session management, authorization, input handling, cryptography, data protection, logging, configuration, and more — organized into chapters and graded into verification levels.

Teams use ASVS to set a security baseline for new features, plan what to test, scope penetration tests, compare vendors, and show auditors and customers what was verified. Version 5.0, released in 2025, reorganized and modernized the requirements. The standard is most valuable when requirements become owned backlog items with recorded evidence, rather than a spreadsheet filled in once.

TL;DR

ASVS is a catalog of verifiable security requirements for applications and APIs; the Top 10 is an awareness list of risks.
Levels set rigor: Level 1 baseline, Level 2 for most applications handling sensitive data, Level 3 for the highest-risk systems.
Requirements have stable identifiers that include the ASVS version, chapter, section, and number.
Scope the application, choose a target level, and mark requirements not applicable with reasons.
Turn requirements into backlog items, tests, and review checklists with named owners.
Record evidence — automated tests, code review records, configuration, pen test results — so verification can be repeated.

Quick Example

A verification plan kept in the repository, mapping ASVS areas to owners, verification methods, and evidence:

The same file drives backlog tickets, pull request checklists, and the scope sent to penetration testers.

Core Concepts

ASVS Versus the Top 10

The Top 10 tells you what commonly goes wrong; ASVS tells you what must be true to prevent it. See OWASP Top 10.

Verification Levels

Choose the target level from the application's risk — data sensitivity, exposure, regulatory obligations — informed by a threat model. Different components can target different levels.

Chapters and Identifiers

Requirements are grouped into chapters covering areas such as encoding and sanitization, validation and business logic, web frontend security, API and web services, file handling, authentication, session management, authorization, tokens, OAuth and OIDC, cryptography, secure communication, configuration, data protection, secure coding and architecture, and security logging and error handling. Each requirement's identifier includes the ASVS version and its chapter, section, and number (for example v5.0.0-1.2.5), so references stay unambiguous across versions.

Applicability

Not every requirement applies — an API without file uploads can skip file handling requirements. Record not applicable decisions with a reason, so reviewers and auditors can see they were considered rather than forgotten.

Putting ASVS to Work

Scope the system: components, data, interfaces, and what is out of scope.
Choose a target level per component, based on risk.
Triage requirements: met, partially met, not met, or not applicable.
Assign owners — teams responsible for each control area.
Create backlog items for gaps, prioritized by risk.
Define verification: automated tests, static and dynamic analysis, code review checklists, configuration checks, or manual testing.
Record evidence and re-verify on a schedule and after significant changes.

Verification Methods

Turn fixed findings into regression tests. See Security Regression Test Suites.

Procurement and Penetration Tests

ASVS gives buyers and testers a shared language: request vendors' ASVS level and evidence, and scope penetration tests by chapters and level so results are comparable and gaps are explicit. See API Security.

Best Practices

Start at Level 1, Plan for Level 2

Reach Level 1 everywhere quickly, then raise critical systems to Level 2 through planned work rather than all at once.

Automate What Can Be Automated

Encode as many requirements as possible in tests and CI checks so verification is continuous rather than annual.

Keep the Mapping With the Code

Store the verification plan in the repository, review changes with code, and update it when architecture changes.

Pair ASVS With Threat Modeling

ASVS covers common controls; threat modeling finds application-specific risks that no generic list contains.

Common Mistakes

Spreadsheet Compliance

One Level for Everything

Treating ASVS as a Pen Test Replacement

FAQ

What is OWASP ASVS?

The Application Security Verification Standard, an OWASP project that defines detailed, testable security requirements for web applications and APIs, organized by chapter and verification level.

Which ASVS level should we target?

Level 1 is the minimum for all applications. Level 2 suits most applications that handle sensitive data or important business functions. Level 3 is for the highest-risk systems. Base the decision on risk and obligations.

How is ASVS different from the OWASP Top 10?

The Top 10 is an awareness document listing major risk categories. ASVS is a requirements standard with specific controls you can design, test, and verify against.

Can ASVS be automated?

Many requirements can be verified with automated tests, static and dynamic analysis, and configuration checks. Others need design review, code review, or manual testing, so a mix of methods is typical.

How do we use ASVS with penetration testing?

Scope tests by ASVS chapters and target level, ask testers to report against requirement identifiers, and track findings as gaps in the same verification plan.