OWASP Application Security Verification Standard (ASVS) OWASP Application Security Verification Standard (ASVS)

By Mark Stenbäck

17.10.2019

This blog entry introduces the OWASP Application Security Verification Standard (ASVS), which is a community-driven project to provide a framework of security requirements and controls for designing, developing and testing modern web applications and services. This text is primarily intended as an introduction for people commonly involved in software acquisition and development projects.

There are four high-level topics:

  • What is the ASVS
  • Security levels of the ASVS
  • Reasons to use the ASVS
  • The ASVS structure

tl;dr: the ASVS is informative and authoritative, which is to say, it is very useful, and most projects would do well to utilize it.

This text is primarily based on OWASP Application Security Verification Standard v4.0.

1 What is the ASVS

“The ASVS is a community-driven effort to establish a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.”

The ASVS version 4.0 was released in March 2019. It was developed in the open and is hosted in GitHub (https://github.com/OWASP/ASVS). As an open project, anyone interested is invited to follow and participate in the development of future versions of the standard, for example, by submitting issues, pull requests and translations.

While there are other standards and practices covering software and information security issues, the ASVS 4.0 strives to become “the leading web applications and services standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture”. With this goal in mind, the ASVS 4.0 is aligned with other well-known projects and standards, such as Common Weakness Enumeration, NIST 80-63-3 Digital Identity Guidelines, and PCI DSS 3.2.1 Requirement 6.5.x for application design, coding, testing, secure code reviews, and penetration tests.

As of version 4.0, the ASVS is intended to become the baseline ASVS for all other related projects, such as the Mobile Application Security Verification Standard (MASVS) and the Internet of Things Application Security Verification Standard (IoT ASVS), which is currently included in the ASVS 4.0 as Appendix C as an early preview.

2 Security levels of the ASVS

The ASVS has two stated primary goals:

  • to help organizations develop and maintain secure applications
  • to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

To accomplish these the ASVS defines three security verification levels starting from basic and progressing to increasingly more demanding requirements.

2.1 ASVS Level 1 - Basic

This is the bare-bones level for low assurance levels and should be considered as the minimum that (most if not) all applications should strive for. Level 1 is the only level that is completely penetration testable without having access to documentation, source code, configuration and/or the development team. However, while the “black box” approach is possible it is by no means recommended as it is completely unable to cope with the harsh realities and security threats of running an application “in production”.

In order to achieve Level 1, the application must “adequately defend against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar checklists”. As such this level is mainly intended for applications that do not handle sensitive data.

2.2 ASVS Level 2 - Standard

This is the recommended level for most applications. At the very least it should be considered when the application handles significant business-to-business transactions or process sensitive (e.g. health care) information, implement business-sensitive / critical functions, or is used in industries where integrity is a critical facet to protect the business.

In order to achieve Level 2, the application must “adequately defend against most of the risks associated with software today” by having security controls in place, effective and used within the application.

2.3 ASVS Level 3 - Advanced

This is the advanced level intended for applications that are used in areas such as military, government, health and safety or critical infrastructure - generally speaking, Level 3 should be applied whenever significant levels of security verification is required.

In order to achieve Level 3, the application must “adequately defend against advanced application [of] security vulnerabilities and also demonstrate principles of good security design”.

A Level 3 application should be meaningfully modularized with multiple layers of security and controls to ensure confidentiality, integrity, availability, authentication, authorization, non-repudiation and auditing. In practice, we are talking about topics such as the proper use of data encryption, input validation, transactions, system scalability, and logging. It should go without saying that proper documentation is also expected.

3 Reasons to use the ASVS

3.1 As Secure Coding Checklist

According to the OWASP, “one of the best ways to use the Application Security Verification Standard is to use it as a blueprint to create a Secure Coding Checklist specific to your application, platform or organization”.

While using automated DAST (Dynamic Application Security Testing), SAST (Static AST) or IAST (Interactive AST) tools are recommended as part of the development process, it should be noted that no more than about half of the ASVS can be completed without human assistance. For example, finding flaws in business logic and access control are (at least in the foreseeable future) beyond the capabilities of automated tools.

3.2 As a framework for Guiding the Procurement of Secure Software

Any person who is about to buy an application or make an order development project would benefit from relying on the ASVS by specifying that the application must meet the requirements for the ASVS Level X. This should ensure that the delivery will meet a certain level of expectations.

This works even better when combined with the OWASP Secure Software Contract Annex.

3.3 As detailed security architecture guide

Even if the ASVS is not directly used in a project, it is a great resource for security/software architects. It lists a wide variety of problems and risks while helping to come up with reasonable solutions.

3.4 As a guide for automated unit and integration tests

By turning the ASVS checks into automated unit and integration tests the quality assurance work can be improved greatly - especially when running these tests as part of the project’s Continuous Integration / Delivery setup.

3.5 As support for secure development training

In many ways, the ASVS defines what “secure software” in practical terms. It will help the developers to focus on proactive controls and reliable solution methods.

3.6 As a driver for Agile Application Security

The ASVS can be included in an agile development process to define specific tasks that need to be implemented in order to have a secure product. These tasks can be included the Product Backlog and discussed with stakeholders as much as they can be used to guide agile design work.

4 ASVS structure

The ASVS 4.0 is divided into 14 chapters.

V1: Architecture, Design and Threat Modelling Requirements

“Security architecture has almost become a lost art in many organisations. … Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single ‘correct’ answer.”

This chapter covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. All these aspects must be built into the application, and usually cannot be meaningfully added as an afterthought at the end of the project.

V2: Authentication Verification Requirements

“Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.”

The classic combination of username and password is no longer enough when security is considered. For example, NIST 800-63 considers these to be public information. A modern application requires a much more robust approach to authentication.

V3: Session Management Verification Requirements

“One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or a device interacting with it.”

This chapter aims to ensure that an application satisfies the following high-level session management requirements:

  • Sessions are unique to each individual and cannot be guessed or shared.
  • Sessions are invalid when no longer required and timed out during periods of inactivity.

V4: Access Control Verification Requirements

“Authorization is the concept of allowing access to resources only to those permitted to use them.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • Persons accessing resources hold valid credentials to do so.
  • Users are associated with a well-defined set of roles and privileges.
  • Role and permission metadata are protected from replay or tampering.

V5: Validation, Sanitation and Encoding Verification Requirements

“The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
  • Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.
  • Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

V6: Stored Cryptography Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • All cryptographic modules fail in a secure manner and that errors are handled correctly.
  • A suitable random number generator is used.
  • Access to keys is securely managed.

V7: Error Handling and Logging Verification Requirements

“The primary objective of error handling and logging is to provide useful information for the user, administrators and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • No collecting or logging [of] sensitive information unless specifically required.
  • Ensure all logged information is handled securely and protected as per its data classification.
  • Ensure that logs are not stored forever, but have an absolute lifetime that is as short as possible.

V8: Data Protection Verification Requirements

There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA).

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • Confidentiality: data should be protected from unauthorized observation or disclosure both in transit and when stored.
  • Integrity: data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
  • Availability: data should be available to authorized users as required.

V9: Communication Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • TLS (Transport Layer Security) or strong encryption is always used, regardless of the sensitivity of the data being transmitted.
  • The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers.
  • Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort.
  • Deprecated or known insecure algorithms and ciphers are disabled.

V10: Malicious Code Verification Requirements

“Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • Malicious activity is handled securely and properly to not affect the rest of the application.
  • [Application] does not have time bombs or other time-based attacks.
  • [Application] does not “phone home” to malicious or unauthorized destinations.
  • [Application] does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.

V11: Business Logic Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • The business logic flow is sequential, processed in order, and cannot be bypassed.
  • Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
  • High-value business logic flows have considered abuse cases malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks.

V12: File and Resources Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

  • Untrusted file data should be handled accordingly and in a secure manner.
  • Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.

V13: API and Web Service Verification Requirements

This chapter aims to ensure that an application that uses trusted service layer APIs (commonly using JSON, XML or GraphQL) has:

  • Adequate authentication, session management and authorization of all web services.
  • Input validation of all parameters that transit from a lower to a higher trust level.
  • Effective security controls for all API types, including cloud and Serverless API.

V14: Configuration Verification Requirements

This chapter aims to ensure that an application has:

  • A secure, repeatable, automatable build environment.
  • Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
  • A secure-by-default configuration, such that administrators and users have to weaken the default security posture.