The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to provide an open application security standard for web apps and web services of all types.
The standard provides a basis for designing, building, and testing technical application security controls, including architectural concerns, secure development lifecycle, threat modelling, agile security including continuous integration / deployment, serverless, and configuration concerns.
Please log issues if you find any bugs or if you have ideas. We may subsequently ask you to open a pull request based on the discussion in the issue. We are also actively looking for translations of the 4.n branch.
The latest stable version is version 4.0.3 (dated October 2021), which can be found:
- OWASP Application Security Verification Standard 4.0.3 English (PDF)
- OWASP Application Security Verification Standard 4.0.3 English (Word)
- OWASP Application Security Verification Standard 4.0.3 English (CSV)
- OWASP Application Security Verification Standard 4.0.3 (GitHub Tag)
The master branch of this repository will always be the "bleeding edge version" which might have in-progress changes or other edits open. The next release target will be version 5.0.
For information on changes between 4.0.2 and 4.0.3 of the standard, see this wiki page and for a full diff, see this pull request.
The OWASP Community effort with regards to translations is a best effort. Whilst we do our utmost to ensure the content is valid, from a structural perspective, there is only so much we can do to ensure the translations are correct. We rely on you, the community, to help make the ASVS as usable as possible to all around the globe, and translating the main branch into your language is important to the project.
If you think you can help with translations, or indeed ensuring the current list of translations below are correct, we'd love for you to join the community and make the ASVS amazing for all. For more information on translating the ASVS see the translations section of CONTRIBUTING.md.
- v4.0.3
- v4.0.2
- OWASP Application Security Verification Standard 4.0.2 German (PDF) and Microsoft Word format. (Thanks to Jörg Brünner)
- OWASP Application Security Verification Standard 4.0.2 Russian (PDF) and Microsoft Word format. (Thanks to Sergey Diakonov)
- v4.0.1
- OWASP Application Security Verification Standard 4.0.1 Persian (PDF) (Thanks to SajjadPourali)
- OWASP Application Security Verification Standard 4.0.1 Japanese (PDF) (Thanks to Software ISAC Japan / Riotaro OKADA)
- OWASP Application Security Verification Standard 4.0.1 Turkish (PDF) (Thanks to Fatih ERSINADIM)
- OWASP Application Security Verification Standard 4.0.1 French (PDF) and other formats. (Thanks to Sebastien gioria and Marc Aubry)
The requirements were developed with the following objectives in mind:
- Help organizations adopt or adapt a high quality secure coding standard
- Help architects and developers build secure software by designing and building security in, and verifying that they are in place and effective by the use of unit and integration tests that implement ASVS tests
- Help deploy secure software via the use of repeatable, secured builds
- Help security reviewers use a comprehensive, consistent, high quality standard for hybrid code reviews, secure code reviews, peer code reviews, retrospectives, and work with developers to build security unit and integration tests. It is even possible to use this standard for penetration testing at Level 1
- Assist tool vendors by ensuring there is an easily generatable machine readable version, with CWE mappings
- Assist organizations to benchmark application security tools by the percentage of coverage of the ASVS for dynamic, interactive, and static analysis tools
- Minimize overlapping and competing requirements from other standards, by either aligning strongly with them (NIST 800-63), or being strict supersets (OWASP Top 10 2017, PCI DSS 3.2.1), which will help reduce compliance costs, effort, and time wasted in accepting unnecessary differences as risks.
ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use.
Each requirement has an identifier in the format <chapter>.<section>.<requirement> where each element is a number, for example: 1.11.3.
- The
<chapter>value corresponds to the chapter from which the requirement comes, for example: all1.#.#requirements are from theArchitecturechapter. - The
<section>value corresponds to the section within that chapter where the requirement appears, for example: all1.11.#requirements are in theBusiness Logic Architecturesection of theArchitecturechapter. - The
<requirement>value identifies the specific requirement within the chapter and section, for example:1.11.3which as of version 4.0.3 of this standard is:
Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.
The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: v<version>-<chapter>.<section>.<requirement>, where: 'version' is the ASVS version tag. For example: v4.0.3-1.11.3 would be understood to mean specifically the 3rd requirement in the 'Business Logic Architecture' section of the 'Architecture' chapter from version 4.0.3. (This could be summarized as v<version>-<requirement_identifier>.)
Note: The v preceding the version portion is to be lower case.
If identifiers are used without including the v<version> element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element.
The entire project content is under the Creative Commons v3.0 license.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent