Convert Figma logo to code with AI

OWASP logoASVS

Application Security Verification Standard

2,720
664
2,720
105
View on GitHub

Top Related Projects

OWASP's avatar

wstg

7,219

The Web Security Testing Guide is a comprehensive Open Source guide to testing the security of web applications and web services.

OWASP's avatar

CheatSheetSeries

27,866

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.

OWASP's avatar

Top10

4,291

Official OWASP Top 10 Document Repository

Quick Overview

The OWASP Application Security Verification Standard (ASVS) is a comprehensive framework for web application security requirements and verification. It provides a basis for testing web application technical security controls and offers developers a list of requirements for secure development.

Pros

  • Provides a comprehensive set of security requirements for web applications
  • Offers different levels of security verification, allowing for flexible implementation
  • Regularly updated to address emerging security threats and best practices
  • Widely recognized and adopted in the industry

Cons

  • Can be overwhelming for beginners or small projects due to its comprehensive nature
  • Requires significant time and resources to fully implement all requirements
  • May not cover all specific security needs for highly specialized applications
  • Some requirements may be challenging to implement in legacy systems

Note: As OWASP/ASVS is not a code library but a security standard document, the code examples and getting started instructions sections are not applicable.

Competitor Comparisons

OWASP logo

wstg

7,219

The Web Security Testing Guide is a comprehensive Open Source guide to testing the security of web applications and web services.

Pros of WSTG

  • More comprehensive testing guide with detailed methodologies
  • Includes practical examples and test cases for each security control
  • Regularly updated with community contributions and emerging threats

Cons of WSTG

  • Larger and more complex, potentially overwhelming for beginners
  • Requires more time to implement all test cases thoroughly
  • May include some outdated information due to its extensive coverage

Code Comparison

WSTG example (SQL Injection testing):

import requests

payload = "' OR '1'='1"
url = f"https://example.com/login?username=admin&password={payload}"
response = requests.get(url)

if "Welcome, admin" in response.text:
    print("SQL Injection vulnerability detected")

ASVS example (Input Validation requirement):

{
  "id": "5.1.1",
  "description": "Verify that the application has defenses against HTTP parameter pollution attacks.",
  "level": 1
}

The WSTG provides specific test cases and code examples, while ASVS focuses on defining security requirements without implementation details.

OWASP logo

CheatSheetSeries

27,866

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.

Pros of CheatSheetSeries

  • More comprehensive coverage of security topics
  • Easier to understand for beginners and non-technical users
  • Regularly updated with new content and best practices

Cons of CheatSheetSeries

  • Less structured approach compared to ASVS
  • May lack the depth required for thorough security assessments
  • Can be overwhelming due to the large number of cheat sheets

Code Comparison

ASVS provides specific requirements, while CheatSheetSeries offers practical examples:

ASVS (example requirement):

V2.1.1 Verify that user set passwords are at least 12 characters in length.

CheatSheetSeries (example guidance):

// Password validation
if (password.length < 12) {
  return "Password must be at least 12 characters long";
}

Both repositories are valuable resources for application security. ASVS offers a structured approach to security verification, while CheatSheetSeries provides practical guidance and examples. ASVS is better suited for formal security assessments, while CheatSheetSeries is more accessible for developers looking to implement security best practices in their code.

OWASP logo

Top10

4,291

Official OWASP Top 10 Document Repository

Pros of Top10

  • Concise and easy to understand, focusing on the most critical security risks
  • Widely recognized and adopted in the industry
  • Provides a good starting point for security awareness and basic risk assessment

Cons of Top10

  • Less comprehensive than ASVS, covering only the top 10 risks
  • May not provide sufficient depth for thorough security testing and verification
  • Updated less frequently than ASVS

Code Comparison

While both repositories don't primarily contain code, they do include examples and references. Here's a brief comparison:

Top10:

<input type="text" name="username" pattern="[a-zA-Z0-9]{5,}" required>

ASVS:

public boolean isValidUsername(String username) {
    return username != null && username.matches("^[a-zA-Z0-9]{5,}$");
}

The Top10 example shows a simple input validation pattern, while ASVS provides a more detailed implementation of the same concept in Java.

Both repositories serve different purposes in the OWASP ecosystem. Top10 is an excellent resource for raising awareness and prioritizing security risks, while ASVS offers a more comprehensive and detailed approach to application security verification.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

OWASP Application Security Verification Standard

CC BY-SA 4.0

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

CC BY-SA 4.0

Introduction

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.

We gratefully recognise the organizations who have supported the project either through significant time provision or financially on our "Supporters" page!

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.

Project Leaders and Working Group

The project is led by the four project leaders Daniel Cuthbert, Jim Manico, Josh Grossman, and Elar Lang.

They are supported by the ASVS Working Group which consists of Shanni Prutchi, Ralph Andalis, Meghan Jacquot, Iman Sharafaldin, and Ryan Armstrong.

Roadmap to ASVS 5.0

We have now published our roadmap and objectives for version 5.0 of the ASVS in this wiki page.

Latest Stable Version - 4.0.3

The latest stable version is version 4.0.3 (dated October 2021), which can be found:

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.

Translations

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.

Standard Objectives

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 2021, 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.

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: all 1.#.# requirements are from the Architecture chapter.
  • The <section> value corresponds to the section within that chapter where the requirement appears, for example: all 1.11.# requirements are in the Business Logic Architecture section of the Architecture 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.

License

The entire project content is under the Creative Commons Attribution-Share Alike v4.0 license.