OWASP ASVS (Application Security Verification Standard): OWASP ASVS – Tutorial (about 60 minutes)

The OWASP Application Security Verification Standard (ASVS) is a free, openly licensed list of security requirements for web applications and web services, written so that each requirement can be checked with a clear pass or fail result. Developers, architects, security testers, product owners and buyers of software use it to agree on what "secure enough" means for a particular application. After this tutorial you will be able to explain how ASVS is organised, choose and justify a verification level, turn ASVS requirements into engineering work and tests, scope and report a verification honestly, and place ASVS next to other OWASP projects and security frameworks.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ASVS 5.0.0, published by the OWASP Foundation (the Open Worldwide Application Security Project, a vendor-neutral non-profit) on 30 May 2025 and marked as the stable release. It replaced version 4.0.3 (October 2021). Version 5.0.0 contains about 345 requirements in 17 chapters, is released under the Creative Commons Attribution-ShareAlike 4.0 licence, and is available as web pages, PDF, Word, CSV and JSON. The project also publishes an automatically generated "bleeding edge" build from its main branch; OWASP says that build is only for preview and testing, so this course teaches 5.0.0. No later stable version (5.0.x, 5.1 or 6.0) had been released when this course was checked. Verified 2026-10-29 on asvs.owasp.org and the project's GitHub releases page.

Who this is for: software developers and tech leads, security champions, application security engineers, penetration testers, architects, product owners, procurement and vendor-risk staff, and auditors who are asked to "build to ASVS" or "test against ASVS Level 2" and want to understand what that really involves.

Prerequisites: none. A rough idea of how a web application works (a browser or mobile app talking to a server over HTTP, a database behind it, users who log in) will help you picture the examples. Security terms are explained the first time they appear.

By the end of this tutorial:

You will be able to explain what ASVS is for, what it covers and what it deliberately leaves out.
You will be able to use the core vocabulary: verification, requirement, level, chapter, section, documented security decision, versioned identifier, consumer, fork.
You will be able to describe the structure of ASVS 5.0 and find the chapters that apply to a given application.
You will be able to choose a target level from risk, not habit, and explain the difference between Levels 1, 2 and 3.
You will be able to turn ASVS requirements into user stories, acceptance criteria, architecture decisions and automated tests.
You will be able to plan, scope and report an ASVS verification, and judge whether someone else's "ASVS compliant" claim is meaningful.
You will be able to relate ASVS to the OWASP Top 10, the Web Security Testing Guide, MASVS, SAMM, NIST SSDF and ISO/IEC 27001.

Lesson 1 – Origins, purpose and scope

The problem ASVS solves

Imagine a company buys a customer portal from a software vendor. The contract says the portal must be "secure". The vendor runs a vulnerability scanner, finds nothing serious, and declares the job done. Six months later an attacker changes the account number in a web address and reads other customers' invoices. Who was wrong? Nobody had written down what "secure" meant, so nobody could prove anything either way.

This is the gap ASVS fills. Security is often described as a list of things to avoid (the famous "top ten" style of awareness list). That is useful for raising awareness, but it is not a specification. You cannot sign a contract, design a feature or write a test plan against "avoid broken access control". You can, however, write a requirement such as "the server checks, on every request, that the caller is allowed to see this particular record", and then check whether the software does it. ASVS is a large, carefully maintained collection of requirements of that second kind.

A short history

According to the preface of version 5.0, the ASVS was first launched in 2008 as a community project. Versions 2 and 3 followed in the mid-2010s, and version 4.0 (2019) became widely adopted; its last update, 4.0.3, appeared in October 2021. Version 5.0.0, released in May 2025, was a major rewrite rather than a refresh. According to the project's own change notes, only a small fraction of the 4.0.3 requirements survived unchanged; many were merged, reworded, moved or deleted, and new chapters were added. If you meet older material that talks about 14 chapters, an "Architecture" chapter V1, or "Level 1 is fully penetration testable", it describes version 4, not version 5.

What ASVS is for

OWASP describes several uses, which you will see throughout this course:

A yardstick for verification – testers and reviewers check an application against a chosen set of requirements and report which pass and which fail.
Security requirements for building software – teams copy the relevant requirements into their backlog, design and coding guidance.
Architecture guidance – architects use the chapters to decide which controls and shared components (for example one authorisation service, one output-encoding library) the system needs.
Procurement – buyers ask suppliers to meet a stated level and to show evidence.
Training – it describes what secure software looks like, which is easier to teach than an endless list of attacks.
Automated testing – many requirements can be turned into unit and integration tests that run on every build.

What is in scope and what is not

ASVS is about the application itself: the security behaviour of the software and of components that process its HTTP traffic, such as a web application firewall, load balancer or reverse proxy when they enforce caching, rate limits or connection rules for the application. It is not a standard for the whole organisation, the data centre, the network or the development process. Things like DNS management, backups and staff security training are out of scope, as are coding style and purely functional quality.

Version 5 applies two filters to every candidate requirement. First, it must have a real security effect. Second, it must be verifiable: a competent reviewer must be able to say pass or fail. That is why ASVS contains only mandatory statements and no gentle suggestions. Good ideas that could not be made mandatory, and secure-development processes such as threat modelling, were moved into an appendix of recommendations, and OWASP points to its other projects (the Software Assurance Maturity Model, the Cheat Sheet Series and the Web Security Testing Guide) for process and how-to advice.

One more scope point surprises newcomers: ASVS is written for web applications and web services, including APIs used by mobile and single-page front ends. Mobile apps as installed on a device have their own sister standard, OWASP MASVS. A mobile product with a server back end usually needs both: MASVS for the app and ASVS for the API it calls.

Lesson 2 – Key concepts and vocabulary

ASVS uses ordinary security words in fairly precise ways. Learn these and the standard becomes much easier to read.

Verification – the act of checking, with evidence, whether an application meets a requirement. ASVS deliberately says "verification" rather than "testing" because the evidence may come from code review, design documents, configuration, interviews or tests.
Requirement – one numbered statement describing a security property the application must have. Each requirement is written so that the result can be pass or fail, and each is assigned to a level.
Chapter – a top-level topic area, such as authentication or cryptography. Chapters are labelled V1 to V17 in version 5.0.
Section – a group of related requirements inside a chapter, for example the password security section inside the authentication chapter.
Control objective – the short introduction at the start of each chapter explaining what the chapter is trying to achieve and why.
Level – one of three tiers (L1, L2, L3) that indicate how much assurance a requirement provides compared with how hard it is to implement. Levels are cumulative: aiming for Level 2 means meeting all Level 1 and Level 2 requirements.
Documented security decision – a requirement that asks the organisation to write down a choice the standard cannot make for everyone, such as which file types may be uploaded, how long an idle session lasts, or which data is classed as sensitive. A matching implementation requirement then checks that the software follows the documented choice.
Identifier – the number of a requirement in the form chapter.section.requirement, for example 6.2.1.
Versioned identifier – the identifier prefixed with the ASVS version and a lowercase v, for example v5.0.0-6.2.1. Because numbers can change between releases, OWASP asks that tools and reports always include the version.
Consumer – a word many ASVS 5.0 requirements use for whoever or whatever calls the application or receives its responses: a human user in a browser, a mobile app, or another service.
Self-contained token – a token, such as a signed JSON Web Token (JWT), that carries its own claims and can be checked without asking a central session store. ASVS gives these their own chapter because they are easy to misuse.
Fork – an organisation's own adapted copy of ASVS, for example with irrelevant sections removed and company-specific guidance added. ASVS encourages forks, provided they keep traceability back to the original requirement numbers.
Hybrid verification – testing that combines running the application with access to its source code, documentation and developers. OWASP strongly prefers this over "black box" testing.
Defence in depth – adding further layers of protection so that one failed control does not lead straight to compromise. Many Level 3 requirements are of this kind.

Two related words are worth separating. A vulnerability is a weakness that could be exploited. A requirement failure in ASVS terms means the application does not show the required property. Every exploitable vulnerability normally maps to one or more failed requirements, but a failed requirement is not always an exploitable vulnerability today. For example, missing security logging is a failure even though nobody can "exploit" it directly. This difference is one reason ASVS reports look different from penetration test reports, as you will see in Lesson 5.

Lesson 3 – Structure of the standard

Front matter and appendices

ASVS 5.0 opens with explanatory chapters: a preface, a chapter explaining what ASVS is (scope, levels, how to use and adapt it), guidance on assessment and certification, and a chapter for people migrating from version 4. The requirement chapters follow. At the end are appendices: a glossary, references, a cryptography appendix with detailed algorithm guidance, a recommendations appendix for items that did not qualify as requirements, and the contributor list. The cryptography appendix matters because the cryptography chapter refers to it for which algorithms and key sizes are acceptable.

The 17 requirement chapters

Version 5.0 organises its requirements into seventeen chapters. In the order they appear, they cover: encoding and sanitisation (V1); validation and business logic (V2); web front-end security (V3); APIs and web services (V4); file handling (V5); authentication (V6); session management (V7); authorisation (V8); self-contained tokens (V9); OAuth and OpenID Connect (V10); cryptography (V11); secure communication (V12); configuration, including backend connections, secret management and unintended information leakage (V13); data protection (V14); secure coding and architecture (V15); security logging and error handling (V16); and WebRTC, the browser technology for real-time audio, video and data (V17).

Seventeen chapters is a lot to hold in your head. The grouping in Figure 1 is not part of the standard; it is a teaching aid that sorts the chapters by the question each one answers.

Figure 1 – The 17 ASVS 5.0 chapters sorted into five themes (a learning aid, not an official grouping).

A few chapters deserve a closer look because they are new or changed in version 5:

Validation and business logic (V2) now sits apart from encoding. Version 5 treats "is this input sensible for our business?" (a quantity cannot be negative, a discount code works once) as a different problem from "is this data safe to place into HTML or SQL?".
Web front-end security (V3) gathers browser-specific protections: cookie attributes, security headers such as HTTP Strict Transport Security and Content Security Policy, separation between origins, and integrity checks for scripts loaded from other sites.
Self-contained tokens (V9) was split out of session management, and OAuth and OIDC (V10) is entirely new, reflecting how many modern applications delegate login to an identity provider and protect APIs with access tokens.
Secure coding and architecture (V15) holds general requirements that did not fit elsewhere: tracking third-party components and their update timelines, keeping an inventory such as a software bill of materials (SBOM) at higher levels, defensive coding, and safe handling of concurrency.
WebRTC (V17) is new and applies only to applications that use real-time media, signalling and relay servers.

The old version 4 chapter on architecture, design and threat modelling no longer exists. Its process-oriented content was judged out of scope, and its technical content was spread across the relevant chapters.

Inside a chapter

Every chapter follows the same pattern. It starts with a control objective, then lists sections, and each section contains a table of requirements with a number, a description and a level. Many chapters begin with a documentation section (for example, the authentication chapter's first section is about documenting how brute-force and credential-stuffing defences work), followed by sections with the technical requirements. Each chapter ends with references to further reading, often OWASP cheat sheets.

Figure 2 – How ASVS is nested: standard, chapter, section and requirement, each requirement carrying a level and a versioned identifier.

A useful habit: when you cite a requirement in a ticket, a contract or a report, always write the versioned form. A bare "6.2.1" is ambiguous, because the same number pointed to a different requirement in version 4 and might point to another again in a future major release.

The three levels

Each requirement is assigned to Level 1, 2 or 3. In version 5.0 the level reflects a judgement of risk reduction versus implementation effort. Risk reduction considers confidentiality, integrity and availability, and whether the control is a first line of defence or an extra layer. Effort considers how hard the control is to build and run.

Level 1 holds the first-layer defences against common attacks, the things every application exposed to the internet should have. It is about one fifth of the standard: 70 requirements in 5.0.0. OWASP keeps it small on purpose so that the entry barrier stays low.
Level 2 adds protection against less common attacks and stronger or more complete protection against common ones. OWASP expects most applications to aim here. Levels 1 and 2 together are roughly 70 per cent of the standard (253 requirements).
Level 3 adds the remaining requirements (92), mostly defence in depth and controls that are expensive or hard to build. It suits applications where a failure would be very serious, for example core banking, critical infrastructure or highly sensitive health data.

Figure 3 – ASVS 5.0.0 levels are cumulative: each level includes every requirement of the levels below it.

Two changes from version 4 matter here. First, Level 1 used to be described as the level that could be checked entirely by black-box penetration testing; version 5 dropped testability as a criterion because how easy something is to test says little about how much it protects. Second, Level 1 shrank sharply, from nearly half of the requirements in 4.0.3 to about a fifth in 5.0.0. An application that was "Level 1" under version 4 is not automatically Level 1 under version 5, and vice versa; you must re-verify.

Some requirements also tighten as the level rises. A requirement may set a baseline at its own level and add a stricter condition "for L2 and up" or "for L3". For instance, the requirement for multi-factor login asks, at Level 3, that one factor be hardware-based and resistant to phishing. Read the whole requirement text, not just the level column.

Version numbering

ASVS uses major.minor.patch numbers. A major release (such as 5.0.0) can reorganise everything and requires a fresh verification. A minor release may add or remove requirements and also requires re-verification, though less work. A patch release may only remove requirements (for example duplicates or outdated ones) or make them less strict, so an application that complied with the previous release still complies.

Lesson 4 – How it works in practice

ASVS does not tell you how to run a development project, but it fits naturally into any lifecycle, agile or not. Figure 4 shows a typical way teams use it, from first decision to ongoing re-verification.

Figure 4 – A typical ASVS adoption loop: decide, tailor, document, build, test, verify, report and repeat.

Step 1 – Define scope and target level

Start by naming what is being verified: which application, which components (web front end, API, admin console, background workers), and which environments. Then choose a target level from risk. Useful questions are: What data does the application hold? What could an attacker do with it? Who uses it, and what would they expect? What do regulators, customers or contracts require? A brochure site with a contact form may start at Level 1; a portal that handles personal health or financial data should aim for Level 2; a system whose compromise could move money at scale or endanger people may need Level 3 for some or all chapters.

Levels need not be uniform. A team can target Level 2 overall and pull specific Level 3 requirements forward where its own threat analysis shows high risk, for example in authentication for administrators. ASVS explicitly allows this kind of prioritisation.

Step 2 – Tailor the standard

Not every chapter applies. A machine-to-machine API has no browser front end, so most of V3 is irrelevant. An application without real-time media can ignore V17. An application that neither issues nor accepts OAuth tokens can skip much of V10. Record what you removed and why. Larger organisations often create a fork: their own version of ASVS with irrelevant sections removed, extra company rules added, and links to approved libraries. The golden rule of forking is traceability. Keep the original versioned identifiers so that "we pass v5.0.0-8.2.2" means the same thing inside and outside the company.

Step 3 – Write the documented security decisions

Many chapters open with documentation requirements. These ask the team to decide and write down rules that only they can set: which input formats are valid, which business limits apply per user and overall, how long sessions may stay idle and how long they may last in total, how many parallel sessions an account may have, which data is sensitive and how each class must be protected, which cryptographic keys exist and how they are managed, what security events are logged and for how long. These decisions are not paperwork for its own sake. They give developers a clear target and give verifiers something concrete to test against. They also give flexibility: version 5 no longer fixes, for example, one universal session timeout, but it does require the team to choose one deliberately and justify it.

Step 4 – Turn requirements into engineering work

Requirements become useful when they live where the work happens. Common techniques are:

Acceptance criteria on user stories: a story for "download my invoices" gets a criterion that the server checks ownership of each invoice requested, which maps to the authorisation chapter's data-level access requirement.
Definition of done entries for the whole team, such as "all database access uses parameterised queries" (injection prevention in V1).
Architecture decisions: choosing one central authorisation mechanism, one secrets vault, one logging pipeline, so that many requirements are met once rather than in every feature.
Security champions in each team who know the relevant chapters and review designs against them.

OWASP's Cheat Sheet Series is the natural companion here: ASVS says what must be true, and the cheat sheets explain how to achieve it in common languages and frameworks.

Step 5 – Build with shared, vetted components

ASVS's recommendations appendix lists principles that make compliance far cheaper: centralise security controls, keep them simple and reusable, prefer well-tested libraries over home-made code, and route every access decision through one mechanism. If ten teams each write their own output encoding, you have ten things to verify. If they all use the framework's encoder, you verify the pattern once and then check that nobody bypasses it.

Step 6 – Automate what can be automated

Requirements that can be checked technically should become automated tests: unit tests that the password-change endpoint asks for the current password, integration tests that one customer's token cannot read another customer's records, checks that responses carry the expected security headers, pipeline jobs that fail the build when a dependency has passed its agreed remediation deadline. Static and dynamic scanners (SAST and DAST) help with some requirements, such as missing encoding or weak TLS settings, if they are tuned so their noise does not hide real issues. But scanners cannot judge business logic or most access control rules. ASVS stresses that "can be automated" does not mean "an off-the-shelf tool will check it"; usually it means the team writes application-specific tests.

Step 7 to 9 – Verify, report, improve

Before an important release, or on a fixed schedule, someone checks the application against the target requirements with evidence. That might be an internal security team, a security champion from another team, or an external firm. Results are reported requirement by requirement, failures are fixed and re-checked, and the cycle repeats as the application changes. Lesson 5 explains this step in detail.

Who does what

Role	Typical ASVS responsibility
Product owner or business owner	Approves the target level and accepts residual risk for exceptions
Architect	Designs shared controls and owns many documented security decisions
Developers	Implement requirements and write the automated tests
Security champion	Keeps the tailored requirement set current and reviews stories
Verifier or tester	Checks requirements with evidence and writes the report
Procurement or vendor risk	Puts the level and evidence expectations into contracts

Lesson 5 – Assessment, certification and compliance

There is no official ASVS certification

This point is simple but often misunderstood. OWASP is vendor-neutral and does not certify applications, vendors, testers or tools against ASVS. There is no OWASP "ASVS certified" badge, no accredited ASVS certification body and no OWASP-run register of compliant products. The standard itself says that any certification or trust mark claiming ASVS is not endorsed by OWASP. Companies are free to offer ASVS-based assessments and to issue their own attestation letters, but they must not present them as official OWASP certification. When you see "ASVS certified" in marketing, ask who verified what, at which level, using which version, and where the report is.

What a good verification looks like

ASVS deliberately does not prescribe a single testing method, but the assessment chapter sets clear expectations:

State the scope and target level, including which requirements were included. Describe what was tested, not only what was left out, and give reasons for excluding requirements.
Use the right method for each requirement. Some requirements are best checked by reading configuration, some by code review, some by running the application, some by reading documentation and interviewing the team. Documentation requirements are verified separately from their matching implementation requirements.
Prefer hybrid verification. Testing without source code or documentation is slower, less thorough and misses missing controls. OWASP strongly recommends documentation-led or source-led testing with access to developers, especially at Levels 2 and 3, and discourages pure black-box testing even at Level 1.
Test with valid accounts. Many requirements (authorisation, session handling, business logic) can only be checked by logging in with different roles.
Keep evidence: notes, screenshots, scripts, logs and code references that let someone else repeat the check. Running a scanner and exporting its findings is not, on its own, an ASVS verification.
Disclose your methods so readers know how much to trust the results, and make them repeatable where possible.

How the report differs from a penetration test report

A classic penetration test report lists what the tester found wrong. An ASVS report lists every requirement in scope with its result. That gives readers a positive statement ("these controls were verified as present") as well as a list of problems. Each requirement ends in one of three states, as Figure 5 shows.

Figure 5 – Each requirement in an ASVS verification ends as pass, fail or not applicable, and failures loop back through remediation.

A typical ASVS report therefore contains: the version of ASVS used, the scope and target level, the methods used, a summary of all checked requirements, details of each failure with guidance on fixing it, and the list of not-applicable requirements with reasons (for example, session management requirements on a stateless API that uses only tokens).

What "compliant" can honestly mean

Because there is no certification scheme, "compliance" with ASVS means only that, for a stated version, scope and level, every applicable requirement was verified as passing, with evidence, and any exclusions were justified. A meaningful claim reads like: "Our customer API passed all applicable ASVS v5.0.0 Level 2 requirements in chapters V1, V2, V4, V6 to V9 and V11 to V16, verified by an independent tester in September 2026; report available under NDA." A meaningless claim reads like: "Our platform is ASVS compliant." Teach your buyers, managers and suppliers to tell the difference.

ASVS in contracts and regulation

ASVS is not a law or a regulatory standard. Its weight comes from adoption: organisations reference it in secure development policies, vendor contracts, bug bounty scopes and internal audit programmes. Auditors working against broader frameworks (for example ISO/IEC 27001's controls on application security requirements and secure coding, or the payment card industry's secure software requirements) often accept ASVS as evidence that an organisation has defined concrete technical requirements. If you use it this way, be explicit about the version and level so the auditor knows exactly what was promised.

Lesson 6 – Worked example

This example is fictional but realistic. It shows how one organisation moves from "we should use ASVS" to a verified release.

The organisation

CareSlot is a 60-person company that runs an appointment booking platform for private clinics. Patients book through a web application and a mobile app; clinic staff use an admin portal; insurers call a partner API to confirm appointments. The platform stores names, contact details, appointment reasons and some insurance numbers. Login for patients uses email and password; clinics log in through their own identity providers using OpenID Connect. A large hospital group wants to sign up, and its procurement team asks for "evidence of secure development against a recognised standard".

Step 1 – Scope and level

The head of engineering, the product owner and a security consultant meet. They list the components: patient web front end, mobile app back-end API, admin portal, partner API and two background workers. The mobile app itself is out of scope for ASVS; they plan to use MASVS for it later. Because the platform holds health-related personal data, they set Level 2 as the target for everything. Their own threat analysis shows that a compromised clinic administrator account could expose thousands of patients, so they also adopt, for administrators and patient records, the stricter Level 3 conditions of two Level 2 requirements: one login factor must be a phishing-resistant hardware authenticator, and every authorisation decision on patient records must be logged, not only refusals.

Step 2 – Tailoring

The security champion builds a spreadsheet from the official ASVS CSV file. She removes WebRTC (no real-time media) and the GraphQL and WebSocket sections of the API chapter (not used). She keeps the OAuth and OIDC chapter but removes its authorisation server, OpenID provider and consent management sections, because CareSlot does not run an identity provider of its own; the generic and client-side sections stay. Each removal gets a one-line reason. About 210 requirements remain. Every row keeps its versioned identifier, such as v5.0.0-8.2.2.

Step 3 – Documented security decisions

Over two weeks the architects write the decisions the remaining requirements call for. A few examples:

Input rules: patient date of birth must be a real date in the past; appointment slots must belong to the clinic shown in the request; a patient may hold at most five future bookings.
Sessions: patient sessions end after 30 minutes of inactivity and after 12 hours in total; admin sessions after 15 minutes idle and 8 hours total; the justification compares these with the NIST digital identity guidance, as the session management chapter asks.
Data classification: appointment reasons and insurance numbers are "restricted"; restricted data must be encrypted at rest, never written to logs, and never cached by browsers.
Files: patients may upload referral letters as PDF or JPEG up to 10 MB; files are stored outside the web root and served only after an ownership check.
Logging: a logging inventory lists which events each layer records, where logs go, who may read them and how long they are kept.
Dependencies: critical vulnerabilities in third-party components must be fixed within 7 days, high within 30 days.

Step 4 – Into the backlog

The team does not create 210 tickets. Instead it groups requirements by shared component. One epic replaces three home-grown permission checks with a single authorisation middleware that checks function-level, record-level and field-level access on every API call; this covers most of the authorisation chapter at once. Another epic moves database credentials and API keys from configuration files into the cloud provider's secrets vault, satisfying the secret management section of the configuration chapter. A third epic adds a second login factor for patients (a one-time code from an authenticator app), because Level 2 requires multi-factor authentication or an equivalent combination of factors for everyone, not only for administrators. Smaller items become acceptance criteria on existing stories: the password change form must ask for the current password; the password policy must require at least 8 characters (15 or more is strongly recommended), allow long passphrases and stop checking for "one capital letter and one symbol", which ASVS no longer allows as a rule; the form must let users paste and use password managers; nobody is forced to change a password on a schedule; and new passwords must be checked against common and breached passwords.

Step 5 – Tests

Developers write integration tests for the authorisation middleware: a patient token requesting another patient's booking gets a refusal; a receptionist from Clinic A cannot list Clinic B's appointments; a changed role takes effect on the next request. A pipeline job checks security response headers on every deployment. The dependency scanner is configured to fail the build when a component exceeds the agreed remediation time. These tests run on every merge, so the team gets continuous evidence for dozens of requirements.

Step 6 – Verification

Three months later CareSlot hires an external application security firm for a hybrid verification. The testers receive the tailored requirement list, the documented decisions, architecture diagrams, source code access, test accounts for every role and a daily call with a developer. They spend eight days. Their report covers every in-scope requirement:

Pass for most requirements, each with evidence (code references, test output, configuration screenshots).
Fail for nine requirements. Two are serious: an older partner API endpoint bypasses the new middleware and allows reading bookings by changing an identifier, and error pages on the admin portal reveal stack traces. Others are smaller, such as a session cookie on the patient site that lacks the HttpOnly attribute, so page scripts could read it.
Not applicable for a handful, with reasons, for example the requirements about concurrent session limits on the partner API, which uses short-lived tokens and has no sessions.

Step 7 – Remediation and the claim

CareSlot fixes the two serious issues within a week and the rest within a month, and the testers re-verify. The product owner formally accepts one low-risk exception with a dated plan. The statement sent to the hospital group's procurement team says: "CareSlot's patient web application, admin portal and partner API meet all applicable OWASP ASVS v5.0.0 Level 2 requirements, plus selected Level 3 conditions for administrator authentication and audit logging, verified by an independent firm in October 2026, with one documented exception. Summary report attached." It does not say "ASVS certified". The hospital's security team reads the report, sees the scope, method and evidence, and approves the supplier.

What made it work

CareSlot chose a level from risk, tailored deliberately, wrote down its decisions, fixed problems in shared components rather than feature by feature, automated the checks it could, used a verifier with full access, and made an honest, specific claim. Those habits matter more than any single requirement.

Lesson 7 – Relationship to other standards and frameworks

ASVS sits inside a family of OWASP projects and alongside broader security frameworks. Knowing which question each one answers stops teams from using the wrong tool for the job.

Standard or framework	Main question it answers	How it relates to ASVS
OWASP Top 10	What are the most important web application risk categories right now?	An awareness document, not a specification. ASVS supplies the detailed, testable requirements behind each risk area.
OWASP Web Security Testing Guide (WSTG)	How do I test a web application for a given weakness?	A testing methodology. ASVS says what must be true; WSTG describes test techniques a verifier can use to check it.
OWASP Cheat Sheet Series	How do I implement this control correctly?	Developer guidance referenced from ASVS chapters; the practical "how" for ASVS's "what".
OWASP MASVS	What security properties should a mobile app have?	Sister standard for apps on the device; ASVS covers the web services the app talks to.
OWASP SAMM	How mature is our software security programme?	Measures organisational practices (governance, design, implementation, verification, operations). ASVS can be the requirement set behind SAMM's security requirements and testing practices.
NIST SP 800-218 (SSDF)	Which secure development practices should a software producer follow?	Process-level practices across the lifecycle; ASVS adds product-level technical requirements.
ISO/IEC 27001	How does an organisation manage information security risk?	A certifiable management system standard. Its Annex A controls on application security requirements, secure coding and security testing can be met in part by adopting ASVS.
NIST SP 800-63B	How should digital identity and authentication work?	ASVS's authentication and session chapters draw on it; version 5 loosened strict alignment but still asks teams to justify deviations.

A good mental model has three layers. At the top, organisational frameworks such as ISO/IEC 27001 and SAMM ask whether you manage security deliberately. In the middle, process frameworks such as the NIST SSDF ask whether your development lifecycle includes the right activities. At the bottom, product standards such as ASVS and MASVS ask whether this specific piece of software has the right security properties. They complement rather than replace each other. An ISO/IEC 27001 certificate says nothing on its own about whether a particular API checks record ownership; an ASVS verification says nothing about whether the company reviews supplier risk each year.

ASVS 5.0 also removed the direct mappings to the Common Weakness Enumeration (CWE) and most strict alignment with NIST SP 800-63 that version 4 carried in its tables. The project found the mappings imprecise and hard to maintain, and plans a link to OWASP's Common Requirement Enumeration (CRE) project instead. If your tooling depends on CWE numbers from version 4, plan for that gap during migration. For teams moving from 4.0.3, OWASP publishes mapping files that trace each old requirement to its version 5 equivalent.

Common pitfalls and best practices

Pitfalls

Treating a scanner run as verification. Automated tools cover only a slice of ASVS and cannot judge business logic or most access rules. A clean scan is not a pass.
Picking a level by habit. Defaulting to Level 1 because it is smallest, or to Level 3 because it sounds best, ignores the risk-based choice ASVS expects. Level 1 alone is rarely enough for applications holding sensitive personal or financial data.
Citing requirement numbers without the version. Numbers moved substantially between versions 4 and 5. A contract that says "meet 2.1.1" may point to an entirely different requirement than intended.
Skipping the documentation requirements. Without written decisions on timeouts, data classes or file types, implementation requirements cannot be verified consistently and every tester invents their own rules.
Claiming "ASVS certified". No such official certification exists; the claim can mislead customers and damage trust when challenged.
Black-box only testing. Denying testers code, documentation and accounts produces slower, shallower results and misses absent controls.
Using version 4 study material for version 5 work. Chapter numbers, level definitions and many requirements changed.
Tailoring without traceability. Renumbering or silently rewriting requirements in an internal fork makes results impossible to compare.

Best practices

Choose and document the target level from risk, and pull specific higher-level requirements forward where your threat analysis justifies it.
Tailor openly: remove chapters or sections that do not apply, record each reason, and keep the original versioned identifiers.
Build shared controls once: one authorisation layer, one encoding approach, one secrets vault, one logging pipeline.
Put requirements where the work happens: acceptance criteria, definition of done, design review checklists.
Automate application-specific tests for access control, authentication flows and business limits, and run them on every build.
Verify hybrid, with evidence, and report every in-scope requirement as pass, fail or not applicable.
Make precise claims that name version, scope, level, verifier, date and exceptions.
Re-verify after major changes and after each new major or minor ASVS release you adopt.

Summary and key takeaways

ASVS is OWASP's free, openly licensed catalogue of testable security requirements for web applications and web services; the current stable edition is 5.0.0 from May 2025.
It covers the security properties of the application, not the organisation, the network or the development process; those belong to other frameworks.
Version 5.0 has about 345 requirements in 17 chapters, each requirement numbered chapter.section.requirement and best cited in versioned form such as v5.0.0-6.2.1.
The three cumulative levels balance risk reduction against effort: Level 1 is a small baseline, Level 2 suits most applications, and Level 3 adds defence in depth for the highest-risk systems.
Documented security decisions let each organisation set rules the standard cannot fix for everyone, and they are verified separately from their implementation.
Good practice is tailor, document, build shared controls, automate tests, then verify with full access and evidence.
OWASP does not certify anything against ASVS; a credible claim states version, scope, level, verifier, method, date and exceptions.
ASVS works alongside the Top 10, WSTG, Cheat Sheets, MASVS, SAMM, NIST SSDF and ISO/IEC 27001, each answering a different question.

Reflection questions

Think of an application you work on. Which ASVS level would you target for it, which specific higher-level requirements might you pull forward, and how would you justify those choices to a sceptical product owner?
Which ASVS chapters would you remove for that application, and what one-line reason would you record for each removal?
List three documented security decisions your team has never written down. Who should own each one, and how would a tester verify the implementation afterwards?
A supplier tells you their product is "ASVS compliant". Write the five questions you would ask before trusting that statement.
Pick one requirement area, such as authorisation or logging. Which parts could your pipeline check automatically, which parts need a human reviewer, and why?