Application Security Verification Standard

The Application Security Verification Standard (ASVS) is a long established OWASP flagship project, and is widely used to suggest security requirements as well as the core verification of web applications.

It can be downloaded from the OWASP project page in various languages and formats: PDF, Word, CSV, XML and JSON. Having said that, the recommended way to consume the ASVS is to access the github markdown pages directly - this will ensure that the latest version is used.

What is ASVS?

The ASVS is an open standard that sets out the coverage and level of rigor expected when it comes to performing web application security verification. The standard also provides a basis for testing any technical security controls that are relied on to protect against vulnerabilities in the application.

The ASVS is split into various sections:

• V1 Architecture, Design and Threat Modeling
• V2 Authentication
• V3 Session Management
• V4 Access Control
• V5 Validation, Sanitization and Encoding
• V6 Stored Cryptography
• V7 Error Handling and Logging
• V8 Data Protection
• V9 Communication
• V10 Malicious Code
• V11 Business Logic
• V12 Files and Resources
• V13 API and Web Service
• V14 Configuration

1. applications that only need low assurance levels; these applications are completely penetration testable
2. applications which contain sensitive data that require protection; the recommended level for most applications
3. the most critical applications that require the highest level of trust

Most applications will aim for Level 2, with only those applications that perform high value transactions, or contain sensitive medical data, aiming for the highest level of trust at level 3.

Why use it?

The ASVS is used by many organizations as a basis for the verification of their web applications. It is well established, the earlier versions were written in 2008, and it has been continually supported since then. The ASVS is comprehensive, for example version 4.0.3 has a list of 286 verification requirements, and these verification requirements have been created and agreed to by a wide security community.

For these reasons the ASVS is a good starting point for creating and updating security requirements for web applications. The widespread use of this open standard means that development teams and suppliers may already be familiar with the requirements, leading to easier adoption of the security requirements.

How to use it

The OWASP Spotlight series provides an overview of the ASVS and its uses: ‘Project 19 - OWASP Application Security Verification standard (ASVS)’.

The appropriate level of verification should be chosen from the ASVS levels:

• Level 1: First steps, automated, or whole of portfolio view
• Level 2: Most applications
• Level 3: High value, high assurance, or high safety

Tools such as SecurityRAT can help create a more manageable subset of the ASVS security requirements, allowing focus and decisions on whether each one is applicable to the web application or not.

The OWASP Cheat Sheets have been indexed specifically for each section of the ASVS, which can be used as documentation to help decide if a requirements category is to be included in the test scheme.

References

• OWASP Application Security Verification Standard (ASVS)
• OWASP Cheat Sheets for ASVS
• OWASP SecurityRAT

The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.

The OWASP ® Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.

Developer Guide

• 1. Introduction
• 2. Foundations
• 2.1 Security fundamentals
• 2.2 Secure development and integration
• 2.3 Principles of security
• 2.4 Principles of cryptography
• 2.5 OWASP Top 10
• 3. Requirements
• 3.1 Requirements in practice
• 3.2 Risk profile
• 3.3 OpenCRE and Integration Standards
• 3.4 SecurityRAT
• 3.5 Application Security Verification Standard
• 3.6 Mobile Application Security
• 3.7 Security Knowledge Framework
• 4. Design
• 4.1 Threat modeling
• 4.1.1 Threat modeling in practice
• 4.1.2 pytm
• 4.1.3 Threat Dragon
• 4.1.4 Cornucopia
• 4.1.5 LINDDUN GO
• 4.1.6 Threat Modeling toolkit
• 4.2 Web application checklist
• 4.2.1 Checklist: Define Security Requirements
• 4.2.2 Checklist: Leverage Security Frameworks and Libraries
• 4.2.3 Checklist: Secure Database Access
• 4.2.4 Checklist: Encode and Escape Data
• 4.2.5 Checklist: Validate All Inputs
• 4.2.6 Checklist: Implement Digital Identity
• 4.2.7 Checklist: Enforce Access Controls
• 4.2.8 Checklist: Protect Data Everywhere
• 4.2.9 Checklist: Implement Security Logging and Monitoring
• 4.2.10 Checklist: Handle all Errors and Exceptions
• 4.3 Mobile application checklist
• 5. Implementation
• 5.1 Documentation
• 5.1.1 Top 10 Proactive Controls
• 5.1.2 Go Secure Coding Practices
• 5.1.3 Cheatsheet Series
• 5.2 Dependencies
• 5.2.1 Dependency_Check
• 5.2.2 Dependency_Track
• 5.2.3 CycloneDX
• 5.3 Secure Libraries
• 5.3.1 Enterprise Security API library
• 5.3.2 CSRFGuard library
• 5.3.3 OWASP Secure Headers Project
• 6. Verification
• 6.1 Guides
• 6.1.1 Web Security Testing Guide
• 6.1.2 MAS Testing Guide
• 6.1.3 Application Security Verification Standard
• 6.2 Tools
• 6.2.1 Zed Attack Proxy
• 6.2.2 Amass
• 6.2.3 Offensive Web Testing Framework
• 6.2.4 Nettacker
• 6.2.5 OWASP Secure Headers Project
• 6.3 Frameworks
• 6.3.1 secureCodeBox
• 6.4 Vulnerability management
• 6.4.1 DefectDojo
• 7. Training and Education
• 7.1 Vulnerable Applications
• 7.1.1 Juice Shop
• 7.1.2 WebGoat
• 7.1.3 PyGoat
• 7.1.4 Security Shepherd
• 7.2 Secure Coding Dojo
• 7.3 Security Knowledge Framework
• 7.4 SamuraiWTF
• 7.5 OWASP Top 10 project
• 7.6 Mobile Top 10
• 7.7 API Top 10
• 7.8 WrongSecrets
• 7.9 OWASP Snakes and Ladders
• 8. Culture building and Process maturing
• 8.1 Security Culture
• 8.2 Security Champions
• 8.2.1 Security champions program
• 8.2.2 Security Champions Guide
• 8.2.3 Security Champions Playbook
• 8.3 Software Assurance Maturity Model
• 8.4 Application Security Verification Standard
• 8.5 Mobile Application Security
• 9. Operations
• 9.1 DevSecOps Guideline
• 9.2 Coraza Web Application Firewall
• 9.3 ModSecurity Web Application Firewall
• 9.4 OWASP CRS
• 10. Metrics
• 11. Security gap analysis
• 11.1 Guides
• 11.1.1 Software Assurance Maturity Model
• 11.1.2 Application Security Verification Standard
• 11.1.3 Mobile Application Security
• 11.2 Bug Logging Tool
• 12. Appendices
• 12.1 Implementation Do's and Don'ts
• 12.1.1 Container security
• 12.1.2 Secure coding
• 12.1.3 Cryptographic practices
• 12.1.4 Application spoofing
• 12.1.5 Content Security Policy (CSP)
• 12.1.6 Exception and error handling
• 12.1.7 File management
• 12.1.8 Memory management
• 12.2 Verification Do's and Don'ts
• 12.2.1 Secure environment
• 12.2.2 System hardening
• 12.2.3 Open Source software

Upcoming OWASP Global Events

Corporate Supporters

OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided without warranty of service or accuracy. For more information, please refer to our General Disclaimer. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright 2024, OWASP Foundation, Inc.