OWASP ASVS: the standard for verifying application security

Version 5.0.0 contains roughly 350 individual requirements split into seventeen thematic chapters by the area they concern. Every requirement is written as a verifiable statement about the application, so it can be answered with met, not met, or not applicable.

The chapters cover authentication, session management, authorization, input validation, cryptography, handling of data, logging, configuration, and other areas. That shape of a verifiable statement is what sets ASVS apart from surveys of risk: a requirement can be picked up and used as an item in an acceptance criterion.

There are three levels and they differ in how many requirements the application has to meet. Level 1 covers roughly a fifth of the requirements and the standard describes it as the minimum worth starting from. Level 2 adds roughly half of them and is the level most applications should aim for according to the standard. Level 3 is the remainder and aims at applications that want to document the highest degree of security.

For the vast majority of company applications, level 2 is the right choice. Level 1 suits a first step with an application you know nothing about yet, and level 3 pays off where failure is irreversible. The standard itself doesn’t prescribe a level and leaves it to risk analysis: as examples it gives an early-stage startup with a limited amount of sensitive data for level 1, and a bank, which in its view would struggle to justify less than level 3. Choosing a level is a decision about budget as much as about scope, because each level adds requirements, not just strictness.

The procedure has three steps: a level is chosen, the requirements that don’t apply to the application are removed, and what remains becomes the list of what has to be verified. That list is also the outline of the report, because each requirement carries its result at the end.

The advantage over an open-ended brief is that the scope is agreed in advance and in writing. Nobody argues after the test about whether something should have been included. The chosen level as an input to the brief of a test therefore saves time on both sides.

ASVS is the only OWASP document that can go straight into a contract, because its requirements are written as verifiable statements. Instead of the sentence “the application will be secure,” an annex names the chosen level and the list of requirements the vendor has to meet.

The difference shows at handover. With a general formulation the dispute is about interpretation; with a specific requirement, fulfillment is verified. Two things are worth adding: who verifies fulfillment, and what happens if a failure is found after handover. Without them the annex stays unenforceable.

The three OWASP documents answer three different questions and in practice are used together. Top 10 says what should worry you, ASVS says what should hold, and WSTG says how to verify it. None of them replaces the other two.

Anyone starting from zero goes through the survey of ten categories of risk first, then chooses an ASVS level, and only then decides on the scope under the WSTG testing guide. The opposite order leads to a test where nobody can say what it was measured against.