OWASP ASVS explained: the security checklist I build web applications to

The point: ASVS is a checklist you build to, not a badge you hold

The OWASP Application Security Verification Standard (ASVS) is an open, community written list of security requirements for web applications and the services behind them.¹ You use it in three ways: to design and build an application securely, to scope the test that checks it, and, as a buyer, to write a clear security requirement into a contract.²

Here is the honest part, and it is the part most sales pages get wrong. ASVS is not a certification you hold. There is no accredited body that issues an "ASVS certificate", and OWASP itself says so plainly: as a vendor neutral nonprofit it does not certify any vendor, verifier or piece of software, and any trust mark claiming official ASVS certification is not endorsed by OWASP.³ So when I say I build to ASVS, I mean something precise. I engineer the application against the standard's requirements, and an independent penetration tester verifies the application against those same requirements and writes up what passed and what did not. The proof is the test report and the fixed findings, not a logo.

That distinction puts ASVS firmly in the engineering discipline, the Tier 4 rigour I build to, rather than with the organisational certifications such as SOC 2 or ISO 27001, which are about an organisation's controls and are issued by third party auditors the client commissions. I come back to that difference below, because a reader often needs both for different reasons. The business in the worked example is invented. The standard and its figures are footnoted.

Who publishes it, and what "open standard" really means

ASVS is a project of the Open Worldwide Application Security Project (OWASP), the same nonprofit behind the widely cited OWASP Top 10 list of common web application risks.¹⁴ The standard is free. You can read it, download it in several formats, and build on it without paying a licence fee, because it is released under a Creative Commons Attribution ShareAlike licence.¹⁵

The current version is ASVS 5.0.0, published on 30 May 2025 at the Global AppSec event in Barcelona.¹ That matters, because 5.0.0 was a major rewrite. OWASP's own versioning rule says a major release can reorganise almost everything, including the requirement numbers, so an application assessed against the older 4.0.3 has to be re evaluated against 5.0.0 rather than assumed to carry over.² If you read older guidance that lists fourteen chapters, it is describing 4.0.3. The current standard has seventeen.

"Open" also means you are encouraged to adapt it. OWASP actively suggests that an organisation fork the standard: start from Level 1 as a baseline, drop the chapters that do not apply to you, such as OAuth or WebRTC if you use neither, and raise the bar per application according to risk.² A tailored ASVS that keeps the original requirement numbers is a feature of the standard, not a misuse of it.

The three levels, and who picks which

ASVS sorts its requirements into three levels of increasing depth. They are cumulative: to meet Level 2 you implement all of Level 1 and Level 2, and Level 3 adds the rest.²

Level 1 is the minimum, a critical starting point of around 20% of the requirements, kept deliberately small to lower the barrier to entry. These are the first layer defences against common attacks that need no special precondition to exploit.²

Level 2 is where most applications that handle meaningful data should aim. Around 50% of the requirements sit at Level 2, so meeting it means implementing roughly 70% of the standard, Level 1 and Level 2 together. These requirements cover less common attacks and the more involved protections against common ones.²

Level 3 is for the highest value or most sensitive systems. It adds the final 30% or so of requirements, mostly defence in depth and controls that are useful but harder to implement.²

OWASP does not tell you which level you must reach. It asks you to look at your own risk and the expectations of your users, then decide. Its own illustration is clear: an early stage startup collecting limited sensitive data might reasonably set Level 1 as its first goal, while a bank would struggle to justify anything below Level 3 for online banking.² For most of the SaaS platforms and online shops I build, Level 2 is the right default, and I reach into Level 3 for the parts that touch the most sensitive data.

The seventeen chapters, and what each one guards against

The roughly 350 requirements are grouped into seventeen chapters, each split into sections.² The grouping is practical: you can switch off a whole chapter that does not apply to you, such as the web front end chapter for a pure machine to machine API.² Here is what each chapter is about, in plain terms.

Chapter	What it guards against
V1 Encoding and Sanitization	Injection and cross site scripting: data is encoded for wherever it lands, so input is never read as code.6
V2 Validation and Business Logic	Malformed input and broken business rules, so a user cannot skip a step or submit a value that should be impossible.
V3 Web Frontend Security	Attacks that run in the browser, handled with security headers, a content security policy and safe use of the page.
V4 API and Web Service	Weak APIs behind the app, including REST and GraphQL, so an endpoint is not an unlocked back door.
V5 File Handling	Unsafe upload, storage and serving of files, so an upload cannot run code or read other files.
V6 Authentication	Weak proof of identity: it covers password rules, multi factor authentication and resistance to guessing and credential stuffing.
V7 Session Management	Stolen or stale sessions, by issuing, protecting and ending sessions correctly.
V8 Authorization	Broken access control, so one user cannot reach another's data or an admin only action.
V9 Self contained Tokens	Forged or replayed tokens such as JWTs that carry their own claims.
V10 OAuth and OIDC	Misuse of the OAuth and OpenID Connect protocols for delegated access and single sign on.
V11 Cryptography	Wrong or weak encryption, hashing and key management, so protected data stays protected.
V12 Secure Communication	Data read or tampered with in transit, through correct transport security (TLS).
V13 Configuration	An application shipped wide open: secure defaults, secrets handling and dependency management.
V14 Data Protection	Careless handling of sensitive data in storage, caches and responses, closely tied to data protection law.
V15 Secure Coding and Architecture	Whole classes of flaw, through architectural and secure coding decisions that are written down and reviewed.
V16 Security Logging and Error Handling	Blind spots and leaks: logging security events usefully without exposing secrets, and failing safely.
V17 WebRTC	Weak real time audio and video connections, for applications that use them.

Two design choices in 5.0.0 are worth knowing. First, some requirements are "documentation requirements": rather than demand that every application encrypt everything or time out every session identically, the standard asks you to write down the decision you took, such as which file types you accept, so a verifier can check both that the decision exists and that the code matches it.² Second, every requirement is phrased as something that must be achieved and results in a clear pass or fail, which is what makes the standard testable at all.²

How ASVS is actually used

The standard earns its keep in three distinct hands.

For the developer, it is a design and build checklist. OWASP positions ASVS as security architecture guidance and as the basis for a secure coding reference: the requirements tell you which controls a secure application needs, and the companion OWASP projects answer the "how" (the Cheat Sheet Series for building, the Web Security Testing Guide for testing).²⁷ I use the relevant chapters as a gate before a feature ships, not as a document read once and filed.

For the tester, it is the scope of the verification. A good ASVS report states which level the application is aiming at and lists every requirement that was in scope, marks each pass or fail, notes the ones that do not apply (session management in a stateless API, for instance) and gives guidance on fixing the gaps.³ That is a far more useful artefact than a traditional penetration test that reports only the failures it happened to find.

For the buyer, it is a procurement requirement you can put in writing. OWASP spells this out: a buyer can simply require that the software be developed to ASVS Level X and ask the seller to prove it.² This is the clause that increasingly lands in enterprise contracts, and it is why a small supplier suddenly needs to care about ASVS: the requirement arrives from a larger customer.

Worked example: a Leeds letting agency SaaS verifies to Level 2

A Leeds company runs a SaaS platform that independent letting agents use to manage tenancies, references and deposit payments, on a domain such as rentdesk.example. It holds tenants' names, addresses and bank details and takes card payments through a payment provider, so it handles meaningful personal data without being a regulated financial institution. Level 2 is the right target.

The trigger is commercial. A national lettings group offers a contract that would double the platform's revenue, and the group's security schedule requires that the software be "developed and independently verified to OWASP ASVS Level 2". Nobody is asking for a badge. They are asking for evidence.

I start with a gap analysis against the seventeen chapters at Level 1 and Level 2. The platform already encodes output and uses parameterised database queries (V1 and V4 look healthy) and runs everything over TLS (V12). The gaps are familiar ones. Admin users log in with a password only, so multi factor authentication is missing (V6). A tenant can load another tenancy's document by changing the number in a URL, a broken access control fault (V8). Uploaded tenancy agreements are served straight back without checking the file type (V5). Security events are barely logged, so an incident would be invisible after the fact (V16). Each gap becomes a fix with a test that proves it stays fixed.

Only once the gaps are closed do I bring in an independent penetration tester, and I give them the documentation and the source, not a locked front door. ASVS is clear that documentation or source led testing, with access to the developers, verifies far more of the standard than black box poking, especially the Level 2 and Level 3 requirements that automated tools cannot reach on their own.³ The tester works through the in scope requirements, confirms the fixes, finds two more issues, and writes the report that the national group asked for. I fix the two findings and the tester retests. The contract proceeds on the strength of a report, not a claim.

Who tests it, and what an independent pen test costs

Some ASVS requirements can be checked with automated tooling. Static and dynamic analysis tools in the build pipeline (SAST and DAST) can catch some issues that should never exist, such as certain encoding failures.³ But OWASP is blunt that "testable using automation" is not the same as "running an off the shelf tool": the harder requirements, business logic and access control above all, need requirements written specifically for your application and, for real assurance, a human tester with access to the documentation and code.³ Much of ASVS has to be verified by hand.

The independent part is the client's to commission. A tester who both builds and signs off the same application is not independent, which is the whole reason the verification is worth something to a buyer. So the honest costing is two lines: my build to the standard, and a separate fee the client pays the tester.

For the tester's fee, the most defensible figures in the UK are the day rates published on the government's Digital Marketplace. On the G Cloud framework, Pen Test Partners list web application penetration testing at £1,200 per day, with specialist roles up to £1,500 per day, and note that professional indemnity insurance is included in the rate.⁸ A focused verification of a single application typically runs to several days, so a realistic range for a small SaaS is a few thousand pounds to the low tens of thousands, depending on scope, whether a retest is included, and whether the quote is before or after VAT. Ask for the price broken into tester days and a day rate, so you can compare like with like. A larger or more sensitive platform aiming at Level 3 costs more, because there are more requirements to verify and more of them need manual work.

ASVS next to SOC 2 and ISO 27001

This is the comparison that stops readers buying the wrong thing. ASVS verifies the security of the application. SOC 2 and ISO 27001 attest to the controls of the organisation.

A SOC 2 report or an ISO 27001 certificate says the company has the right policies, access reviews, change management and monitoring around its systems. It is produced by an independent auditor or certification body that the company commissions and pays. It says relatively little about whether a given screen in your product is vulnerable to broken access control. ASVS says a great deal about that screen and nothing about whether your HR offboarding process revokes access on time.

So they answer different questions, and a buyer often wants both: the organisational certification to trust the company, and an ASVS verification to trust the software. A specialised payment focused standard, PCI DSS, sits alongside again if you store or process card data. The shortest way to hold the three apart: ISO 27001 and SOC 2 are about the organisation, PCI DSS is about the cardholder data environment, and ASVS is about the application itself.

Where ASVS sits, and who does not need it

Honesty cuts both ways, so here is who can relax. If you are building a brochure site with a contact form and no login, the full weight of ASVS is overkill; a handful of Level 1 items covers you. A very early product still finding whether anyone wants it can reasonably set Level 1 as its first goal and move up as it starts to hold real data, exactly as OWASP suggests.² The standard is a ladder, not an all or nothing gate, and its lowest rung is meant to be easy to reach.

The flip side is cost, stated plainly. Building to Level 2 or Level 3 adds real work to the build itself: the fixes, the tests, the documentation requirements. On top of that the client pays the independent tester separately. Neither of those is a hidden fee I bury. They are the price of being able to prove, rather than assert, that the software is secure, and for a business critical platform that proof is usually worth more than it costs.

How I build to ASVS

In a Ruby on Rails SaaS or a Solidus shop, most of ASVS is ordinary, disciplined engineering rather than a product you buy.

Authentication and authorization (V6 and V8) mean multi factor authentication on every admin path and access checks enforced on the server for every request, never hidden in the front end. Encoding and validation (V1 and V2) are largely what the framework gives you when you use it properly: parameterised queries and contextual output encoding. For cryptography and data protection (V11 and V14), Rails ships Active Record Encryption for encrypting sensitive attributes at the application level, so bank details and references are not sitting in plain text.⁹ Against the guessing attacks that Level 1 authentication targets, Rails has a built in rate limit for controllers that throttles repeated login and password reset attempts.¹⁰ Logging and error handling (V16) means recording security events that someone actually reviews, while never writing a secret into a log.

I run a penetration testing pass with the Kali Linux toolkit, using tools such as Nmap, Burp Suite and OWASP ZAP, before anything faces the internet, and every finding is written up with a severity and a fix. That pass is my own quality gate. It does not replace the client's independent verification against ASVS; it means the independent test finds far less, and what it finds is smaller.

What to do now

Work through this in order.

First, decide the level from your risk, not from a brochure: Level 1 for a low data product, Level 2 for most platforms that hold meaningful data, Level 3 for the most sensitive. Second, run a gap analysis against the chapters at that level while the application is still being built, because fixing a design fault is far less expensive before launch than after. Third, write down the decisions the documentation requirements ask for, so there is something for a verifier to check against. Fourth, commission an independent, source led penetration test mapped to your chosen level, and budget for it as a separate line the client pays. Fifth, fix the findings and retest, then keep the report: that report, and the fixes behind it, are the proof, and they are worth more than any badge.

If your own customers have started asking you to prove your software is secure, or a contract now names an ASVS level, that is the moment to build to the standard properly rather than scramble for a certificate that does not exist.

Footnotes

1. OWASP, Application Security Verification Standard, project site, version 5.0.0 published 30 May 2025, licensed under Creative Commons Attribution ShareAlike 4.0, https://asvs.owasp.org/ ↩ ↩² ↩³ ↩⁴

2. OWASP, Application Security Verification Standard 5.0.0, "What is the ASVS?" (scope, the three levels, the seventeen chapters, documentation requirements, release strategy, forking, reference format and use cases including procurement), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵

3. OWASP, Application Security Verification Standard 5.0.0, "Assessment and Certification" (OWASP does not certify any vendor, verifier or software, plus verification reporting and scope, and the roles of automated tooling and source led penetration testing), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x04-Assessment_and_Certification.md ↩ ↩² ↩³ ↩⁴ ↩⁵

4. OWASP, OWASP Top 10 project, the standard awareness document for common web application security risks, https://owasp.org/www-project-top-ten/ ↩

5. Creative Commons, Attribution ShareAlike 4.0 International licence, legal text, https://creativecommons.org/licenses/by-sa/4.0/ ↩

6. OWASP, Application Security Verification Standard 5.0.0, chapter V1 Encoding and Sanitization (example requirement v5.0.0 1.2.5 on protecting against operating system command injection), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x10-V1-Encoding-and-Sanitization.md ↩

7. OWASP, Web Security Testing Guide, the companion project on how to test web application security controls, https://owasp.org/www-project-web-security-testing-guide/ ↩

8. UK Government Digital Marketplace, G Cloud, Pen Test Partners penetration testing pricing document (web application testing £1,200 per day, specialist rates to £1,500 per day, professional indemnity insurance included), published 28 January 2026, https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-15/documents/701263/429516649648249-pricing-document-2026-01-28-0919.pdf ↩

9. Ruby on Rails Guides, Active Record Encryption, guides.rubyonrails.org, https://guides.rubyonrails.org/active_record_encryption.html ↩

10. Ruby on Rails API, ActionController::RateLimiting::ClassMethods, rate_limit, api.rubyonrails.org, https://api.rubyonrails.org/classes/ActionController/RateLimiting/ClassMethods.html ↩