OWASP ASVS: A Blueprint for Verifying and Engineering Secure Applications
How can you verify that your application is truly secure? The OWASP ASVS provides an answer to this question with its systematic approach to application security.
Whether you're an architect designing software systems, a developer implementing features, a QA engineer ensuring requirements are met, or a security professional conducting security assessment, you've likely grappled with questions like:
How do you design a system that's secure by default?
How do you ensure your code isn't vulnerable to injection attacks?
How do you verify that authentication controls work as intended?
And —maybe most importantly— how do we know if our security measures are appropriate for our specific context?
ASVS answers all these questions with a systematic approach that adapts to your security needs, whether you're building a simple CRUD application or a critical financial system.
In this deep dive, we'll explore how ASVS can help you approach application security in a systematic way. We'll break down its structure, understand its levels, and learn how to apply it practically in your projects. Let's begin!
Understanding ASVS
The Application Security Verification Standard (ASVS) is a comprehensive standard that transforms application security into a structured, verifiable process. Through its three-level approach, it provides specific, actionable requirements—both functional and non-functional—that scale with your security needs.
ASVS has evolved significantly since its first release in 2009. The current version (4.0), released in 2019, reflects more than a decade of real-world application security experience and community feedback.
The 14 Security Domains
At its core, ASVS is organised into 14 security domains:
Architecture, Design and Threat Modeling
Authentication
Session Management
Access Control
Validation, Sanitisation and Encoding
Stored Cryptography
Error Handling and Logging
Data Protection
Communications
Malicious Code
Business Logic
File and Resources
API and Web Service
Configuration
Each domain provides an overview, specific security controls, and detailed references. What makes ASVS particularly powerful is its modular structure—domains are further divided into focused sub-areas that can be applied selectively based on your application's architecture.
Take the API and Web Services domain, for instance. It includes sub-areas for:
Generic Web Service Security
RESTful Web Service
SOAP Web Service
GraphQL
This modular approach makes ASVS highly practical. For example, if you're building a modern application using REST and GraphQL (but not SOAP), you can focus specifically on:
Core API security requirements that apply universally
REST-specific security controls
GraphQL-specific security measures
This targeted approach ensures you implement precisely the security controls relevant to your technology stack, without getting bogged down in inapplicable requirements.
ASVS Security Levels
In the introduction, we mentioned security levels, and that wasn't a casual reference—each ASVS control belongs to one of three levels, where each subsequent level raises the security bar higher.
Let's look at a practical example. Control 13.2.2 states that "when using JSON, schema validation must occur before accepting input data" and is required from level one upward:
However, control 13.2.5, which requires "REST services must verify the expected Content-Type," only applies at levels 2 and 3. This means applications targeting only level 1 compliance can skip this requirement:
You might be wondering, "What determines the appropriate level for my application?" The consultant in me wants to say "It depends!"—and it does—but let me give you some concrete guidance.
Level 1: The Security Baseline
Level 1 (L1) requirements target projects with basic security needs. Think of it as your essential security baseline—one that can be largely (though not entirely) verified through automated testing. Importantly, L1 requirements cover most of the OWASP Top 10 vulnerabilities. (This means implementing ASVS L1 as part of your secure development process effectively addresses nearly all OWASP Top 10 risks.)
💡 NOTE: See our previous article if you aren’t familiar with OWASP Top 10.
A crucial point about L1: it's the only level that can be fully tested using a black-box approach—testing without access to documentation, source code, or the development team. However, the ASVS authors (with whom we agree 100%) strongly caution against relying solely on black-box testing. Here's why:
In the real world, attackers have unlimited time while security testers face strict deadlines
Effective testing requires maximum insight into the application
Consider this: Would you trust a financial audit where the auditor couldn't access accounting records or talk to the finance team? Yet this scenario plays out regularly in application security testing. That's why ASVS promotes comprehensive security testing that combines traditional testing with code reviews, architectural analysis, and direct collaboration with development teams.
Level 2: Business-Critical Security
Level 2 (L2) targets applications handling important business operations—like processing personal data under GDPR. In practice, L2 is recommended for most applications with user data. Meeting L2 requirements means your application has effective controls against common security issues (e.g. you shouldn’t find basic vulnerabilities like XSS in a search bar).
Level 3: High-Security Applications
Level 3 (L3), the highest tier, is designed for critical applications—think financial systems or medical data processors. These are applications that demand the highest level of trust. L3-compliant applications must excel not just in implementation security but also in architectural design, incorporating secure architecture principles like Defense in Depth or Least Privilege.
Choosing the Right Level
Ultimately, choosing the right ASVS level depends on two contexts: your system's requirements and your organisation's environment. It's simple logic—you expect different security levels from a banking application compared to a meme-sharing website.
Related Standards and Alignment
While ASVS is unique in its domain, as there are no other similar industry standards, OWASP itself maintains several complementary verification standards:
OWASP Mobile Application Security Verification Standard (MASVS), which adapts ASVS principles for mobile applications
OWASP Internet of Things Verification Standard (ISVS), which extends ASVS concepts to IoT and embedded systems
OWASP Software Component Verification Standard (SCVS) addresses supply chain security; however, for practical supply chain security, consider the SLSA framework instead
Also, it’s worth pointing out that ASVS doesn't exist in isolation—it's carefully aligned with established industry standards like PCI DSS and NIST frameworks. Most notably, ASVS controls map to the Common Weakness Enumeration (CWE), providing a bridge between ASVS and the vulnerability classifications discussed in the OWASP Top 10.
💡 NOTE: See our previous article if you aren’t familiar with OWASP Top 10 or CWE.
Practical Applications of ASVS
Role-Based Implementation
ASVS serves as a versatile tool that can be utilised throughout the entire software development lifecycle. For example:
Architects can leverage ASVS during the design phase to establish secure architecture foundations and define comprehensive security requirements.
Developers can integrate ASVS into the implementation phase through Secure Code Checklists, making security verification a natural part of code reviews.
QA Engineers can utilise ASVS Level 1 requirements to validate fundamental security properties, incorporating security testing into standard quality assurance.
Last, but not least, Security Teams can conduct thorough security assessments using ASVS Levels 2 and 3, ensuring applications meet advanced security requirements.
But ASVS can go beyond the development teams, as Project Managers can incorporate ASVS into third-party software contracts, using specified ASVS levels as concrete acceptance criteria for the software delivered.
Measuring Security Progress
What makes ASVS particularly valuable is its ability to track security progress over time. Unlike broader frameworks such as OWASP Top 10, ASVS provides detailed, measurable criteria that enable organisations to:
Monitor security improvements across development cycles
Maintain consistent security standards across projects
Demonstrate concrete security progress to stakeholders
Aaaand that’s all for today. Best regards and see you next week!
BTW. If you found this article useful, please pay the fee by sharing it with someone you know will also benefit from it. Thank you very much! 🙏