Application Security Verification Standard
The Application Security Verification Standard (ASVS) is a long established OWASP flagship project, and is widely used to identify gaps in security as well as the 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
- applications that only need low assurance levels; these applications are completely penetration testable
- applications which contain sensitive data that require protection; the recommended level for most applications
- 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.
How to use it
The ASVS is a list of verification requirements that is used by many organizations as a basis for the verification of their web applications. For this reason it can be used to identify gaps in the security of web applications. If the ASVS suggests using a control then that control should be considered for the application security, it may be not applicable but at least the control should have been considered at some point in the development process.
The OWASP Spotlight series provides an overview of the ASVS and its uses: ‘Project 19 - OWASP Application Security Verification standard (ASVS)’.
The OWASP Cheat Sheets have been indexed specifically for each section of the ASVS, which can be used as documentation on controls for a given requirements category.
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
- 5.4 Implementation Do's and Don'ts
- 5.4.1 Container security
- 5.4.2 Secure coding
- 5.4.3 Cryptographic practices
- 5.4.4 Application spoofing
- 5.4.5 Content Security Policy (CSP)
- 5.4.6 Exception and error handling
- 5.4.7 File management
- 5.4.8 Memory management
- 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
- 6.5 Verification Do's and Don'ts
- 6.5.1 Secure environment
- 6.5.2 System hardening
- 6.5.3 Open Source software
- 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