The OWASP Application Security Verification Standard (ASVS) is a list of security requirements you can test an application against. Where the OWASP Top 10 is an awareness document describing the categories of risk that matter most, ASVS is the verification checklist , hundreds of specific, testable requirements organized by security domain.
If the Top 10 tells you what tends to go wrong, ASVS tells you exactly what to verify.
Why it exists
“Is our application secure?” is unanswerable as asked. ASVS reframes it into something testable: which requirements does this application meet, and at what level? That gives three things a Top 10 conversation cannot:
- A defined standard to test against, rather than a tester’s personal judgment.
- Evidence of coverage, including the requirements that passed.
- A shared vocabulary between security, engineering, and procurement , you can put “verified to ASVS Level 2” in a contract.
The three levels
ASVS is tiered so the standard scales with risk. You pick the level that matches what the application handles.
Level 1 , Opportunistic. The baseline every application should meet. Requirements at this level are testable entirely from the outside, without source code or credentials, which makes L1 suitable for automated scanning plus light manual testing. Appropriate for applications with no sensitive data at all.
Level 2 , Standard. The level most applications should target. It covers applications handling personal data, business-critical functions, or anything a regulator would care about , which in practice means nearly every SaaS product, portal, or line-of-business application. L2 requires manual testing, because the requirements cover authorization logic, session handling, and business logic that no scanner evaluates.
Level 3 , Advanced. For applications where failure is severe: medical, financial, defence, critical infrastructure. Requires the most thorough verification, including source-code review and architectural analysis.
The practical guidance: if the application handles personal or financial data, target Level 2. L1 is the floor, not the goal, and L3 is reserved for genuinely high-consequence systems.
What the standard covers
ASVS organizes requirements into chapters, each covering a security domain. The main areas:
- Architecture and threat modelling , design-level requirements, trust boundaries, and documented security decisions.
- Authentication , credential strength, multi-factor, recovery flows, and credential storage.
- Session management , token generation, timeout, invalidation on logout, and cookie attributes.
- Access control , the domain where most real breaches occur: enforcing authorization on every request, at object level, server-side.
- Input validation and encoding , injection prevention across SQL, command, template, and deserialization contexts.
- Cryptography , algorithm choice, key management, and randomness.
- Error handling and logging , logging security events without leaking sensitive data.
- Data protection , data at rest and in transit, caching, and retention.
- Communications , TLS configuration and certificate handling.
- Malicious code, business logic, files, and APIs , including dedicated requirements for REST, GraphQL, and web service security.
- Configuration , dependency management, security headers, and hardened defaults.
Recent versions have restructured and consolidated these chapters, so always work from the version number you have agreed with your tester , requirement IDs differ between releases.
ASVS vs. the OWASP Top 10
They are complementary, not alternatives:
| OWASP Top 10 | OWASP ASVS | |
|---|---|---|
| Purpose | Awareness of common risks | Verification standard |
| Size | 10 categories | Hundreds of requirements |
| Use | Training, prioritization | Testing, contracts, procurement |
| Answers | “What usually goes wrong?” | “Does this app meet requirement X?” |
| Granularity | Risk categories | Specific, testable controls |
A test scoped to “the OWASP Top 10” tells you the tester looked for those risk categories. A test scoped to “ASVS Level 2” tells you exactly which of hundreds of requirements were verified, and which failed. The second is far more useful as evidence , which is why security-mature buyers increasingly ask for it by name.
How to actually use ASVS
As a development standard. Choose your level, and treat the relevant requirements as acceptance criteria. Engineers get a concrete definition of “secure enough” instead of an abstraction.
As a penetration testing scope. Specify the level in your statement of work: “verified against ASVS Level 2.” You then receive a report that maps findings to requirement IDs and shows coverage, rather than a list of whatever happened to turn up.
As a procurement requirement. If you buy software that handles your data, asking a vendor which ASVS level their application has been verified to is a sharper question than “is it secure?” , and the quality of the answer is itself informative.
As a gap analysis. Work through the requirements for your target level and mark met, not met, or not applicable. The result is a prioritized security backlog grounded in a recognized standard.
A caution: ASVS at Level 2 or 3 is a large standard. Do not attempt every requirement in one cycle. Start with the chapters covering your highest risk , access control and authentication for most applications , and expand from there.
ASVS in a penetration test
Scoping a test to ASVS changes the deliverable in three ways. The report maps findings to requirement IDs, so remediation tickets reference a standard rather than an opinion. It documents coverage, including passed requirements, which is exactly what auditors and enterprise customers want to see. And it makes engagements comparable year over year , you can demonstrate movement from partial L2 coverage to full L2 coverage.
This is how we structure web application penetration testing: the OWASP Testing Guide provides the methodology, ASVS provides the requirement set, and the report shows both what failed and what was verified.
The short version
ASVS is the standard to reach for when “we follow the OWASP Top 10” stops being a sufficient answer. Pick Level 2 for anything handling real data, use it as both a development standard and a testing scope, and insist your penetration test reports against it. The result is evidence rather than assurance.
If you want your application verified against ASVS with a report that maps findings to requirement IDs, scope an assessment and tell us which level you are targeting.
Written by
Invadel Team
Senior penetration testers writing from real engagements — the same team that scopes, tests, and reports for our clients. About Invadel →