Even a simple website often relies on complex platforms, such as CMS (content management systems) or APIs.
Safety must no longer be an afterthought. It’s a basic requirement.
The OWASP ASVS, Application Security Verification Standard, is a set of requirements for designing, developing, testing and confirming application security.
ASVS is a standard maintained by the OWASP community. The latest version is 5.0.0 (May 2025).
The aim of ASVS is to reduce the attack surface, raise the security posture and increase the confidence of users and partners.
It’s a set of tools, frameworks and references that I strongly encourage you to discover and use!
ASVS 5.0 principles
Version 5 has been designed around a number of principles:
Application: what we secure is the application itself: its code, its configurations and the components that apply controls (e.g. authentication, authorization).
Safety: every requirement must reduce a real risk.
Verification, everything needs to be testable with a clear result (pass/fail) and supporting evidence. Scans help, but we also check business logic and access.
Standard, ASVS says what must be true, not how to do it. It’s a set of technical requirements, agnostic to tools and technology.
Next, an increasingly important item is the “documentation of safety decisions” to track design choices and facilitate their verification.
Finally, version 5 has revised the 3 levels to make them easier to use.
Why OWASP ASVS
OWASP ASVS provides a common language and a clear checklist for securing applications. For an SME, it’s a simple way to avoid blind spots, align the team and prove that security is taken seriously.
Standardize what counts.
ASVS offers a consistent set of requirements applicable to all your projects.
Cover all controls.
From authentication to session management, from data validation to cryptography, ASVS includes it all. By following it, we reduce the classic risks (SQL injection, XSS access control failures) that cause the majority of incidents.
Facilitate safety testing.
ASVS provides concrete verification criteria for manual and automated testing. These criteria can be integrated into quality assurance processes or continuous integration.
Increase developer maturity.
Guidelines make security more tangible for the team. They understand why a control is required and how to implement it correctly.
Improving safety posture.
With the ASVS standard, deviations are identified more quickly and dealt with before they become critical vulnerabilities.
Support regulatory compliance.
ASVS helps demonstrate that appropriate controls are in place, facilitating compliance. Demonstrate to customers and auditors that application security is managed in a structured way.
Reduce costs.
Correcting during development is much cheaper than rushing in after an incident. Preventing breaches also avoids fines, legal fees and lost business.
Gaining the trust of users.
More secure applications mean fewer security flaws. In a competitive market, this trust becomes a clear advantage.
How the levels work: L1, L2, L3
The ASVS proposes three levels of increasing priority for the 345 items.
- L1 (Level 1):70 controls (basic security, covering known risks and easy to test, for low-risk applications).
- L2 (Level 2): 183 controls (advanced protection for applications handling sensitive data).
- L3 (Level 3): 92 controls (maximum security required for critical applications, such as healthcare or financial applications).
The ASVS does not impose any particular level. It’s your risk analysis, the sensitivity of the application and the expectations of your users that should guide your choice.
What are “documented safety decisions”?
Documented safety decisions” means that everything the organization chooses in terms of safety and functions must be written down.
ASVS 5.0 calls for choices to be drafted, shared and traceable.
During the audit, we check that these decisions exist and are feasible, and that the code, configurations and processes apply exactly what has been decided.
Example: The first name field must be less than 50 letters long. When validating by integration, numbers must be rejected and more than 50 letters as well.
What the ASVS contains
The standard comprises 345 requirements in 17 chapters, each divided into thematic sections:
This structure allows you to choose what’s relevant to the context; for example, a machine-to-machine API will ignore “V3-frontend web” requirements.
The ASVS deliberately uses the word “requirement”: it states what must be true (“must”), not optional “shoulds”. The idea is to aim for clear, easy-to-understand safety objectives that are not tied to a specific technology, and this makes the verification method independent.
I invite you to click on “Follow” to continue learning more about information security and privacy topics.
