OWASP ASVS 5.0: Levels, Chapters and How to Use It in Development

The OWASP ASVS (Application Security Verification Standard) answers the question the OWASP Top 10 leaves open: what exactly does a secure web application have to do? Where the Top 10 lists ten categories of risk to raise awareness, the ASVS lists around 350 specific, verifiable requirements, grouped by topic and graded into three levels of assurance. Developers can build to it, testers can verify against it, and buyers can write "ASVS Level 2" into a contract and know what they are asking for.

Version 5.0, published on 30 May 2025, was a substantial rewrite: chapters were reorganised, requirements were made clearer and more testable, and new areas such as OAuth and OIDC, self-contained tokens and WebRTC got their own chapters. This guide explains how the standard is structured, how to choose a level, how to use it across the development life cycle and in contracts, and how it relates to the Top 10, SAMM, the SSDF and PCI DSS.

What is the OWASP ASVS?

The ASVS is a community standard from the OWASP Foundation that provides a basis for testing web application technical security controls and a list of requirements for secure development. It is used to:

• Define security requirements for new applications and features.
• Guide secure design and coding, together with the OWASP Cheat Sheet Series.
• Scope and structure security testing, whether code review, automated testing or penetration testing.
• Set expectations in procurement and contracts, by specifying a level.

Requirements are referenced with a version prefix, such as v5.0.0-1.2.5 for requirement 5 in section 1.2 of version 5.0.0, because numbering changes between versions.

History and why it was created

The ASVS was first published in 2008, to give organisations a consistent way to specify and verify application security rather than relying on ad hoc checklists. Version 3 (2015) and version 4 (2019) expanded it significantly and aligned it with NIST's digital identity guidelines and modern architectures. Version 4.0.3 (2021) became widely referenced. Version 5.0.0, released in May 2025, restructured the standard into new chapters, removed duplication, clarified levels, and added coverage for modern patterns such as token-based authentication, OAuth and OIDC flows, and real-time communication.

Who should use the ASVS?

• SaaS companies and agencies building web applications and APIs.
• Security testers and penetration testing firms that want consistent, comparable scopes.
• Enterprises buying or commissioning software, which can specify a level in contracts.
• Teams preparing for PCI DSS requirement 6, the EU Cyber Resilience Act or customer security reviews.

It is global and voluntary. Some regulators and industry schemes refer to it, but its force usually comes from contracts and internal policy.

The three levels

Level	Intended for	What it means
Level 1	All applications	The first layer of defence: requirements that every application should meet, focused on the most critical and common weaknesses.
Level 2	Most applications handling sensitive data or business transactions	The recommended level for most applications, adding requirements that defend against more capable attackers and cover more areas.
Level 3	Critical applications (high-value transactions, health, safety, critical infrastructure)	The highest assurance, requiring defence in depth and more rigorous controls throughout.

Levels are cumulative: Level 2 includes Level 1 requirements, and Level 3 includes both. Choose the level based on the data and functions at risk, not on the size of the company.

The chapters of ASVS 5.0

Chapter	Topic	Examples of what it covers
V1	Encoding and Sanitization	Context-aware output encoding, injection prevention, safe deserialisation
V2	Validation and Business Logic	Input validation, business rules enforced on the server, anti-automation
V3	Web Frontend Security	Security headers, cookie settings, content security policy, browser protections
V4	API and Web Service	HTTP methods, content types, GraphQL and WebSocket considerations
V5	File Handling	Upload restrictions, storage, download and processing of files
V6	Authentication	Password policy, multi-factor authentication, credential recovery, defences against credential stuffing
V7	Session Management	Session creation, timeout, termination and re-authentication
V8	Authorization	Access control design, operation-level and data-level authorisation
V9	Self-contained Tokens	Validation and use of tokens such as JWTs
V10	OAuth and OIDC	Secure client, authorisation server and resource server configuration
V11	Cryptography	Algorithms, key management, randomness, hashing
V12	Secure Communication	TLS configuration and service-to-service communication
V13	Configuration	Secure defaults, secrets management, dependency and build configuration
V14	Data Protection	Sensitive data identification, client-side storage, data minimisation
V15	Secure Coding and Architecture	Architecture documentation, dependency management, safe coding patterns
V16	Security Logging and Error Handling	What to log, log protection, error handling that does not leak information
V17	WebRTC	Security of real-time communication features

Moving from ASVS 4.0.3 to 5.0

Many contracts and internal standards still cite version 4.0.3. The 5.0 release is not a minor update, so a direct find-and-replace of requirement numbers does not work. The main differences to plan for:

• New chapter structure: topics were regrouped, and modern patterns such as self-contained tokens, OAuth and OIDC, and WebRTC now have their own chapters.
• Rewritten requirements: many were made more precise and testable, merged or split, so the count and numbering differ.
• Clarified levels: Level 1 is framed as the first layer of defence for every application rather than only what can be tested from the outside, and Level 2 is positioned as the standard for most applications.
• Versioned references: OWASP recommends citing requirements with the version prefix to avoid confusion.

When moving, re-run the gap assessment against 5.0 rather than translating old results, and update contract templates to cite the new version explicitly.

Level 2 in practice: where applications usually fall short

Gap assessments against Level 2 tend to find the same handful of issues in otherwise well-built applications:

• Authorisation at the data level. Endpoints check that a user is logged in but not that the specific record belongs to them or their tenant. The fix is a central authorisation layer with ownership checks and automated tests per role.
• Session handling. Long-lived sessions with no idle timeout, no re-authentication before sensitive actions and no way for users to see and end other sessions.
• Credential recovery. Reset tokens that are reusable, long-lived or sent in ways that leak them.
• Security logging. Authentication events, authorisation failures and admin actions not logged with enough context, or logs containing secrets and personal data.
• Configuration and secrets. Secrets in source code or environment files committed by mistake, debug features enabled, and outdated dependencies.
• File handling. Uploads stored in web-accessible locations without type, size and content checks.

Fixing these in shared components usually brings an application most of the way to Level 2.

How to use the ASVS across the life cycle

Requirements and design

Pick the target level for the application. Turn relevant requirements into acceptance criteria on user stories, for example "password reset tokens are single-use and expire" for a recovery feature. During design reviews, check architecture against V15 and the chapters that match the feature.

Development

Give developers the relevant chapter and the matching OWASP Cheat Sheets. Encode common requirements into shared libraries and framework configuration: one authorisation middleware, one output encoding approach, one session configuration, so each team does not reinvent them.

Testing

Map automated tests and scanners to requirements where possible, and use the ASVS to scope manual testing and penetration tests. Report results by requirement so gaps are clear. Not every requirement can be tested from the outside; some need code review or architecture review.

Procurement and contracts

Specify the level and any exclusions, how verification will be done (independent test, code review or self-assessment), and how findings will be handled. This is far clearer than "free of OWASP Top 10 vulnerabilities".

A step-by-step adoption plan

1. Choose a level per application, documenting the reason.
2. Run a gap assessment against that level, chapter by chapter.
3. Prioritise gaps by risk; authentication, authorisation and input handling usually come first.
4. Build shared controls into frameworks and libraries.
5. Add requirements to the definition of done and code review checklists.
6. Automate verification where possible; schedule manual verification for the rest.
7. Verify independently for high-risk applications, at least annually and after major changes.
8. Track compliance by requirement and re-assess when you upgrade to a new ASVS version.

Documentation you will need

• Level selection and scope per application.
• Requirement mapping showing status and evidence for each applicable requirement.
• Architecture and data flow documentation (V15).
• Security test plans and results mapped to requirements.
• Exceptions with risk acceptance and owners.

Verification and certification

OWASP does not certify applications or vendors against the ASVS. Claims of "ASVS certified" products should be read as statements by a tester or vendor, not OWASP endorsement. What customers can rely on is a verification report from a competent tester stating the version, level, scope, method and results, together with the remediation status.

Timeline and cost considerations

Level 1 is achievable for most well-built applications with moderate effort. Level 2 typically requires deliberate work on authentication, session management, authorisation, logging and configuration. Level 3 needs architectural decisions and more rigorous verification. Costs include developer time, security testing, tooling and documentation. Building shared controls into frameworks is the main way to keep the cost per application low.

Benefits and the risk of not using it

The ASVS makes security requirements explicit, testable and comparable across projects and suppliers. It reduces arguments about what "secure" means, improves test coverage, and gives a defensible standard of care. Without a standard like it, security depends on individual developers' knowledge, penetration tests vary widely in scope, and contracts contain vague promises.

Common mistakes and challenges for IT companies

• Choosing Level 3 everywhere, creating unrealistic work; or Level 1 for applications holding sensitive data.
• Treating it as a penetration test checklist only. Many requirements are about design and code.
• Citing requirements without a version, which becomes ambiguous after updates.
• Each team implementing controls differently instead of sharing libraries.
• No exception process, so unmet requirements are silently ignored.

Best practices, tools and technologies

• Keep an ASVS requirements matrix per application in your repository or GRC tool.
• Use framework security features and centralise authorisation, encoding and session handling.
• Pair ASVS chapters with OWASP Cheat Sheets in developer onboarding.
• Use the OWASP Web Security Testing Guide for test techniques.
• Combine with OWASP SAMM to improve the process that produces compliant code.

We build web applications and APIs against ASVS requirements and fix findings from client security tests.

How the ASVS relates to other frameworks

Framework	Relationship
OWASP Top 10	Awareness list of risk categories; the ASVS provides the detailed requirements to address them.
OWASP SAMM	Measures the maturity of the development process; the ASVS defines the application requirements.
NIST SSDF	Secure development practices that reference the ASVS for requirements.
PCI DSS	Requirement 6 secure development can be supported by building to an ASVS level.
PCI Secure Software Standard	Payment software requirements that overlap with ASVS topics.
Cyber Resilience Act	EU essential requirements for products; ASVS helps implement them for web components.

Real-world implementation examples

Many penetration testing firms structure web application tests and reports by ASVS chapters, and some government and enterprise procurement frameworks specify ASVS levels for applications they buy. Large organisations publish internal security standards derived from the ASVS.

An illustrative case for a SaaS company selling to banks: the bank requires ASVS Level 2. A gap assessment shows strong encoding and TLS configuration but gaps in session management, authorisation tests and security logging. The company centralises authorisation checks, adds automated tests per role, configures session timeouts and re-authentication for sensitive actions, and implements structured security logging. An independent test against Level 2 confirms the changes, and the report becomes part of its sales evidence pack.

Next steps

1. Choose a target level for each application.
2. Run a gap assessment against ASVS 5.0.
3. Fix authentication, authorisation and input handling gaps first.
4. Build shared controls and add requirements to the definition of done.
5. Verify independently and keep a versioned requirements matrix that sales and customers can rely on.
6. Update contract templates to cite ASVS 5.0.0 and the level explicitly.

Frequently asked questions

What is the latest version of the OWASP ASVS?

ASVS 5.0.0, published on 30 May 2025.

What is the difference between ASVS and the OWASP Top 10?

The Top 10 is an awareness document listing risk categories. The ASVS is a detailed standard of testable requirements in three levels.

Which ASVS level should we choose?

Level 1 for all applications, Level 2 for most applications handling sensitive data or transactions, and Level 3 for critical applications. Base the choice on risk.

Can an application be ASVS certified?

OWASP does not certify applications. A tester can verify and report compliance with a stated version and level.

How many requirements are in ASVS 5.0?

Around 350, across 17 chapters.

Does the ASVS cover APIs?

Yes. It has a dedicated chapter for API and web service security, plus chapters on tokens and OAuth and OIDC.

How should we cite ASVS requirements?

With the version prefix, for example v5.0.0-1.2.5, because numbering can change between versions.

Does ASVS apply to mobile apps?

It applies to the web services and APIs they use. For the mobile app itself, OWASP publishes the Mobile Application Security Verification Standard (MASVS).

Can we use ASVS in contracts?

Yes. Specify the version, level, scope, verification method and how findings are handled.

Do we have to meet every requirement at our level?

Requirements that do not apply to your application, such as WebRTC requirements for an application without real-time communication, can be marked not applicable. Requirements that apply but are not met should go through a documented exception with an owner and a risk decision.

How often should we verify against the ASVS?

At least annually for important applications, after major changes, and continuously for requirements that can be checked automatically in the pipeline.

Is ASVS useful for PCI DSS?

Yes. Building and testing to an ASVS level supports PCI DSS secure development and testing requirements, though it does not replace PCI DSS validation.