OWASP Application Security Verification Standard
What is the ASVS?
The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.
The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:
- Use as a metric - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
- Use as guidance - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
- Use during procurement - Provide a basis for specifying application security verification requirements in contracts.
Get the latest stable version of the ASVS (4.0.3) from the Downloads page and the plan and roadmap towards ASVS version 5.0 has been announced!
How To Reference ASVS Requirements
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 theArchitecture
chapter. - The
<section>
value corresponds to the section within that chapter where the requirement appears, for example: all1.11.#
requirements are in theBusiness Logic Architecture
section of theArchitecture
chapter. - The
<requirement>
value identifies the specific requirement within the chapter and section, for example:1.11.3
which 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.
ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use.
Related Projects
OWASP Resources:
Example
Put whatever you like here: news, screenshots, features, supporters, or remove this file and don’t use tabs at all.
ASVS Supporters
Introduction
Within the ASVS project, we gratefully recognise the following organizations who support the OWASP Application Security Verification Standard project through monetary donations or allowing contributors to spend significant time working on the standard as part of their work with the organization.
We recognise various tiers of support and the amount of time the supporter is recognised for depends on the supporter level.
On this page and the project web page, we will display the supporter’s logo and link to their website and we will publicise via Social Media as well.
If you would like to directly become a Primary, Secondary or Tertiary supporter, you can make a donation to OWASP of $1,000 or more and choose to “restrict your gift”. Alternatively, when you pay your corporate membership you can choose to allocate part of your membership fee to the ASVS where the allocated amount will govern which level of supporter you become.
Maintaining Supporters (through time provision)
Organizations who have allowed contributors to spend significant time working on the standard as part of their working day with the organization. This will be evaluated at the sole discretion of the project leaders. Supporter will be listed 2 years from the end of the time provision.
Primary supporters
Organizations who have donated $7,000 or more to the project via OWASP. Supporter will be listed in this section for 3 years from the date of the donation.
Secondary supporters
Organizations who have donated $3,000 or more to the project via OWASP. Supporter will be listed in this section for 2 years from the date of the donation.
Tertiary supporters
Organizations who have donated $500 or more to the project via OWASP. Supporter will be listed in this section for 1 year from the date of the donation.
Associate supporters
Organizations who have donated another amount to the project via OWASP. Supporter will be listed in this section for 1 year from the date of the donation.
News and Events
- [22 May 2022] Started recognising time and financial supporters of the ASVS.
- [15 May 2022] The plan and roadmap towards ASVS version 5.0 was announced!
- [28 October 2021] ASVS 4.0.3 released!
- [27 October 2020] ASVS 4.0.2 released!
- [2 March 2019] ASVS 4.0.1 released!
- [9 March 2018] OWASP ASVS 3.1 Spreadsheet created by August Detlefsen
- [29 June 2016] Version 3.0.1 released
- [9 Oct 2015] Version 3.0 released
- [20 May 2015] “First Cut” Version 3.0 released
- [11 Aug 2014] Version 2.0 released
Acknowledgements
Note that since 4.x, contributors have been acknowledged in the “Frontispiece” section at the start of the ASVS document itself.
Time and financial supporters are recognised on the “Supporters” tab.
Volunteers
Version 3 (2015)
Project Leaders
- Daniel Cuthbert
- Andrew van der Stock
Lead Author
- Jim Manico
Other reviewers and contributors
- Boy Baukema
- Ari Kesäniemi
- Colin Watson
- François-Eric Guyomarc’h
- Cristinel Dumitru
- James Holland
- Gary Robinson
- Stephen de Vries
- Glenn Ten Cate
- Riccardo Ten Cate
- Martin Knobloch
- Abhinav Sejpal
- David Ryan
- Steven van der Baan
- Ryan Dewhurst
- Raoul Endres
- Roberto Martelloni
Version 2 (2014)
Project leaders
- Sahba Kazerooni
- Daniel Cuthbert
Lead authors
- Andrew van der Stock
- Sahba Kazerooni
- Daniel Cuthbert
- Krishna Raja
Other reviewers and contributors
- Jerome Athias
- Boy Baukema
- Archangel Cuison
- Sebastien.Deleersnyder
- Antonio Fontes
- Evan Gaustad
- Safuat Hamdy
- Ari Kesäniemi
- Scott Luc
- Jim Manico
- Mait Peekma
- Pekka Sillanpää
- Jeff Sergeant
- Etienne Stalmans
- Colin Watson
- Dr. Emin İslam Tatlı
Translators
- Abbas Javan Jafari (Persian)
- Sajjad Pourali (Persian)
Version 2009
Project leader
- Mike Boberski
Lead authors
- Mike Boberski
- Jeff Williams
- Dave Wichers
Other reviewers and contributors
Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.
OWASP Summer of Code 2008
The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.
Glossary
- Access Control – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
- Application Component – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
- Application Security – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
- Application Security Verification – The technical assessment of an application against the OWASP ASVS.
- Application Security Verification Report – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
- Application Security Verification Standard (ASVS) – An OWASP standard that defines four levels of application security verification for applications.
- Authentication – The verification of the claimed identity of an application user.
- Automated Verification – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
- Back Doors – A type of malicious code that allows unauthorized access to an application.
- Blacklist – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
- Common Criteria (CC) – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
- Communication Security – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
- Design Verification – The technical assessment of the security architecture of an application.
- Internal Verification – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
- Cryptographic module – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
- Denial of Service (DOS) Attacks – The flooding of an application with more requests than it can handle.
- Dynamic Verification – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
- Easter Eggs – A type of malicious code that does not run until a specific user input event occurs.
- External Systems – A server-side application or service that is not part of the application.
- FIPS 140-2 – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
- Input Validation – The canonicalization and validation of untrusted user input.
- Malicious Code – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
- Malware – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
- Open Web Application Security Project (OWASP) – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security “visible,” so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
- Output Validation – The canonicalization and validation of application output to Web browsers and to external systems.
- OWASP Enterprise Security API (ESAPI) – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
- OWASP Risk Rating Methodology – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
- OWASP Testing Guide – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
- OWASP Top Ten – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
- Positive – See whitelist.
- Salami Attack – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
- Security Architecture – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
- Security Control – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
- Security Configuration – The runtime configuration of an application that affects how security controls are used.
- Static Verification – The use of automated tools that use vulnerability signatures to find problems in application source code.
- Target of Verification (TOV) – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the “Target of Verification” or simply the TOV.
- Threat Modeling - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
- Time Bomb – A type of malicious code that does not run until a preconfigured time or date elapses.
- Verifier - The person or team that is reviewing an application against the OWASP ASVS requirements.
- Whitelist – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.
ASVS Users
CREST OWASP Verification Standard (OVS) Programme
The CREST OWASP OVS Programme accredits companies that provide app security testing services to the application development industry. The testing to be performed is based on the ASVS (and MASVS) projects.
App Defense Alliance
The App Defense Alliance has based its Cloud Application Security Assessment (CASA) program on the ASVS project.
Other users
A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including:
- Booz Allen Hamilton
- CGI Federal
- Denim Group
- Etebaran Informatics
- Inspectiv - “We use ASVS in our pen tests in order to have a comprehensive, vendor neutral, guideline for testing the security of applications and websites.”
- Minded Security
- Nixu
- NVISO - “We use the ASVS as a baseline for our Web Application Penetration Tests.”
- Pensive Security
- ps_testware
- Proactive Risk
- Quince Associates Limited (SeeMyData)
- ReqView - “We use the ASVS as a document template in ReqView requirements management tool and demonstrate its usage in our Example project.”
- Serviço Federal de Processamento de Dados (SERPRO)
- Universidad Distrital Francisco José de Caldas
Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization’s name, and brief description of how you use the standard. The project leads can be reached using the contact details on the main page.