All You Need to Know About OWASP ASVS 4.0

The OWASP ASVS is widely known across the cybersecurity paradigm as a detailed list of security requirements and guidelines that can be used by developers, architects, security experts, tests and even consumers to design, build and test highly secure applications.

● Using it as a well-defined metric for application owners and developers who could verify the level of security their applications possessed.

● Using it as suitable guidance for developers so that they could build effective security controls into their applications.

● Using it during the procurement of tools and services and ensuring that essential security requirements were met.

The depth of OWASP ASVS kept on increasing with time and the culmination of community efforts and feedback led to the introduction of the latest version of ASVS, i.e. ASVS version 4.0. So, let’s take a look at all the things you need to know about ASVS 4.0 and much more.

Application Security Verification Standards

Now that we know what ASVS is all about, it’s time to briefly discuss the latest versions of ASVS, i.e. ASVS 3.0 and the latest ASVS 4.0:

ASVS 3.0:

ASVS 3.0 was released after the massive success of the previous versions in October 2015. Expanding the security requirements established by the previous versions, 3.0 provided guidelines on how the security systems in modern web applications could be verified. Also, it had suggestions regarding the necessary security levels in various web and mobile applications.

In 3.0, several new sections were added, including Web Services, Configuration, and Modern (Client) based apps to make the standard widely applicable. Special attention was given to the security of more responsive applications with extensive add-ons like HTML5, RESTful APIs, and SAML authentication.

ASVS 4.0:

The much anticipated ASVS version 4.0 was released by the OWASP community in March 2019. The community-led project is also hosted openly on GitHub. The most highlighting additions to this version were compliance with NIST 800-63-3 Digital Identity Guidelines and mapping with Common Weakness Enumeration (CWE).

The ASVS version 4.0 is all set to become the baseline standard for other related projects like the Internet of Things Application Security Verification Standard (IoT ASVS) and the Mobile Application Security Verification Standard (MASVS).

Difference Between ASVS 4.0 over ASVS 3.0

As compared to version 3.0 of the OWASP ASVS, the 4.0 version includes the following major changes and additions:

● As compared to the previous version, DevSecOps practices have been introduced in the latest version.

● The document has been restructured and renumbered. Requirements have been split and subchapters added which makes the document easy to follow.

● Key Vaults and GUIDs (Globally Unique Identifiers) are covered in the latest version. In the list of assets to protect, caches, backups, and other secondary data storage have been included.

● An entire new section has been added on Privacy Controls.

● New password-related requirements have been added, including password replacement and complexity requirements. Authentication tokens and password managers have been promoted.

● Threat Modelling has been introduced by expanding the Business Logic Verification Requirements section.

What does the New ASVS 4.0 Cover?

The most crucial addition to the OWASP’s ASVS 4.0 version is the addition of NIST 800-63-3 Digital Identity Guidelines where modern and advanced evidence-based authentication controls are adopted. Moreover, this version has been completely renumbered from start to finish. This has made the document easy to follow as the longer chapters have been segmented into a number of simpler ones.

The 4.0 version also maps comprehensively with the highly demanded Common Weakness Enumeration (CWE) where users can match their vulnerability assessment results from other tools and previous versions of ASVS. The security checklist in version 4.0 also meets the requirements of OWASP Top 10 2017 and OWASP Proactive Controls 2018.

In order to establish compliance with the PCI DSS 3.2.1 regulation, ASVS 4.0 also covers unsafe memory operations and buffer overflow in chapter 5, and chapter 14, it covers unsafe memory-related compilation flags. ASVS has also shifted from providing only server-side controls to covering all applications and APIs.

However, in the latest version, less impactful controls have been retired and the mobile section is planned to be replaced by Mobile Application Security Verification Standard (MASVS). From version 4.0 onwards, the OWASP community has decided that ASVS will solely focus on being the leading standard for web apps and cover modern agile and DevSecOps practices.

Application Security Verification ( ASVS ) Levels 

Starting from basic and moving above toward more demanding requirements, ASVS has three levels of security verification:

ASVS Level 1 Basic

ASVS Level 1 is for basic applications which don’t have confidentiality as a priority and are less vulnerable to cyber attacks. However, this basic level of security assurance must be fulfilled by every application. The security controls enlisted in this level protect the application from well-known vulnerabilities and all the measures are penetration testable without requiring access to source code or configurations.

ASVS Level 2 Standard

ASVS Level 2 is something that security experts recommend for most applications. The applications which regularly handle business-to-business transactions must follow the level 2 guidelines. The security controls mentioned in this level protect the application from invalid access control, injection flaws, authentication, and validation errors, and so on. ASVS Level 2 ensures that the controls for security effectively align with the level of threat the application is exposed to.

ASVS Level 3 Advanced

This is the highest level of security that can be built into an application. ASVS Level 3 is generally preferred by applications that aim for a significant level of security like healthcare, military, and other critical applications. Meeting the level 3 standards require applications to build security layers from the beginning and also document and audit their efforts.

ASVS 4.0 Structure

The ASVS document consists of the following chapters which cover detailed instructions on specific security requirements

V1: ARCHITECTURE, DESIGN, AND THREAT MODELLING REQUIREMENTS

The very first chapter of ASVS 4.0 covers the elementary features of all security architectures, i.e. privacy, availability, confidentiality, non-repudiation, and integrity. As an update from the previous versions, the importance of threat modeling in the present security systems is also stressed.

V2: AUTHENTICATION VERIFICATION REQUIREMENTS

Modern and robust methods of authentication have been discussed in the second chapter of ASVA 4.0. It is very well known that just a combination of username and password is not enough and more stringent measures, including hashing and other advanced cryptographic methods, need to be implemented.

V3: SESSION MANAGEMENT VERIFICATION REQUIREMENTS

This portion of the OWASP ASVS makes sure the application in focus has the following session management features:

● Sessions can not be shared or guessed and are unique for each individual.

● Session timeout occurs after an adequate period of inactivity and the session becomes invalid.

V4: ACCESS CONTROL VERIFICATION REQUIREMENTS

The fourth chapter of the document sets up guidelines to make sure that the application fulfills the following access control requirements:

● Only those with the required credentials can access the resources in focus.

● Specific privileges and roles are assigned to only a certain set of users.

● Access control and permission metadata are secured effectively to prevent tampering and theft.

V5: VALIDATION, SANITATION, AND ENCODING VERIFICATION REQUIREMENTS

The chapter on validation, sanitation, and encoding requirements sets up standards such that:

● Injection attacks should be prevented by setting up a secure pipeline for input validation and output encoding.

● Input data is properly validated and filtered, i.e. its range and length are checked properly.

● Output data is properly encoded and its context is well-protected from infiltrators.

V6: STORED CRYPTOGRAPHY VERIFICATION REQUIREMENTS

The chapter on cryptography stresses the following key factors:

● Make sure that the application’s error handling is robust and that all the cryptographic modules used are fail-safe.

● An efficient random number generator is used which meets the purpose of the application’s cryptographic requirements.

● Secure access to the cryptographic keys is maintained.

V7: ERROR HANDLING AND LOGGING VERIFICATION REQUIREMENTS

The seventh chapter in the ASVS 4.0 document is about logging and error handling and focuses on the following criterion:

● Do not collect or create logs of sensitive user information unless necessary.

● Make sure that the logged data is handled with the utmost care and protected according to compliance requirements.

● Make sure that the collected data is not retained for long and is deleted after a certain specified duration of time.

V8: DATA PROTECTION VERIFICATION REQUIREMENTS

The chapter on data protection requirements stresses more on the aspects of confidentiality, integrity, and availability:

● The confidentiality of the data must be maintained during both storage and transit.

● Data must be protected from malicious alteration or deletion by threat actors.

● The availability of data must be ensured to authorized users at all times.

V9: COMMUNICATION VERIFICATION REQUIREMENTS

The chapter on communication requirements guides the developers to use strong encryption or transport layer security at all times. It is also advised to use the most novel configuration algorithms and reduce reliance on the weak and soon-to-be deprecated ones. It’s a recommended practice to disable insecure ciphers and algorithms in order to maintain the security of the application data.

V10: MALICIOUS CODE VERIFICATION REQUIREMENTS

The chapter on malicious code aims to make sure that the following high-level requirements are met:

● Handling of malicious activity is done in a manner so that the rest of the application is not affected by it.

● The application in focus doesn’t have entities like time bombs (time-based attacks), easter eggs, rootkits, or other unauthorized material that could be controlled or executed by the threat actors.

V11: BUSINESS LOGIC VERIFICATION REQUIREMENTS

The eleventh and one of the most crucial chapters of the document make sure that the following business logic requirements are met:

● The business logic is designed in a manner so that it can’t be bypassed by threat actors.

● That the business logic flow is processed in order and is sequential.

● The business logic has flags to detect attacks and mitigate them.

● The business logic is designed to address security flaws like repudiation, spoofing, data theft, tampering, and other attacks.

V12: FILE AND RESOURCES VERIFICATION REQUIREMENTS

The next chapter in the ASVS 4.0 document deals with the following file and resource requirements:

● Data from untrusted sources must be handled in a manner compliant with regulations.

● Data from third-party and untrusted sources must be stored out of the webroot and given limited permissions

V13 API AND WEB SERVICE VERIFICATION REQUIREMENTS

This part of the standard recommends that the APIs of the application fulfill the following requirements:

● The APIs have an adequate authorization, essential session management parameters, and authentication to access all the web services.

● The APIs have proper input validation in case their parameters are transiting from lower to higher trust levels.

● The various application APIs like the cloud and serverless APIs have all the essential security controls.

V14: CONFIGURATION VERIFICATION REQUIREMENTS

The last chapter in this OWASP standard concerns several configuration requirements including:

● The built environment of the application must be secure and automatable.

● The third-party libraries must be adequately assessed and the application must have a suitable configuration and dependency management system to filter out insecure components.

Where else can ASVS be Used?

Aside from being used as a leading security assessment standard, the OWASP ASVS can be used for several other purposes. Let’s take a look at them:

1. As a Detailed Guidance on Application Security Architecture

A very common use of ASVS is as a critical resource for application security architects. Security architects generally use ASVS to decide robust controls for common security loopholes like input validation and data protection patterns.

2. As a Replacement for Off-the-Shelf Checklists about Secure Coding

By choosing one of the three levels of ASVS, many businesses can fulfill the requirement of following a standard security audit checklist. They can specifically choose what is needed for each risk level and also specific to the domain of the application.

3. As Guidance for Integrated and Automated Tests

When used as a guide for integrated and automated tests ASVS lets the application become self-verifying with each subsequent build. Using ASVS, developers could design tests on login controllers, SQL injection, brute force attacks, XSS, and more.

4. For Secure Development Training

Another use of ASVS is as a standard to define the essential characteristics of secure software. While the conventional coding techniques aren’t that beneficial for developers, ASVS, on the other hand, could be used to develop proactive security controls and not just focus on bug fixing.

5. As a Framework for Agile Application Security

One of the most exciting applications of ASVS could be as a guiding framework for agile application security. Development teams could implement the secure practices mentioned in the ASVS and build a secure and robust product. Following ASVS guidelines could help in prioritizing security tasks like auditing and reviewing and making everything visible, as in a standard agile process.

6. As a Framework to Procure Secure Software

Another great application of ASVS could be as a framework to aid the procurement of secure software or certain development services.

The buying party can simply state their demand that the product must satisfy a certain level X of ASVS and the seller is obliged to prove that their product does that actually. When combined with another standard procurement procedure called the OWASP Secure Software Contract Annex, the whole process works even better.

OWASP ASVS Checklist for Security Audit

The ASVS checklist for security audits consists of the following sections covering verification requirements on all three ASVS levels. Let’s briefly discuss each one of them:

● Architecture: This section on the checklist covers requirements across all 14 chapters ranging from verification of the use of threat modeling to verifying the application’s trust boundaries and access control mechanisms.

● Authentication: The checklist of authentication covers requirements like verifying password security credentials, credential storage requirements, and service authentication requirements.

● Session Management: The checklist section on session management covers the intricacies ranging from session logout and timeout requirements to cookie-based and token-based session management.

● Access Control: This portion of the checklist stresses on verifying general access control design to operation levels access control requirements like sensitive data and API security.

● Input Validation: This checklist section guides developers to verify that all input is validated using adequate validation and that user input is properly sanitized to avoid injection attacks.

● Cryptography at Rest: This portion of the checklist requires the developers to verify that sensitive user, financial, or healthcare data is stored encrypted and that proper algorithms and ciphers are used to authenticate the encrypted data.

● Error Handling and Logging: This section on error handling and logging provides security guidelines for verifying the contents of logs, log processing requirements, and log protection requirements.

● Data Protection: This part enlists detailed requirements on general and client-side data protection and also on sensitive data protection.

● Communication Security: This checklist for security audit highlights verification requirements like the use of trusted TLS certificates, authentication of server communications, and so on.

● Malicious Code: This section stresses on verifying the use of code analysis tools, managing permissions, malicious code search, and verifying deployed application integrity controls.

● Business Logic: All the verification requirements related to the application’s business logic are enlisted in this section.

● Files and Resources: All the file-related security requirements including upload, integrity, execution, storage, download, and SSRF protection requirements are enlisted here.

● Web Service: Security requirements like generic web service, RESTful web service, SOAP web service, and GraphQL-based verification requirements are covered in this section.

● Configuration: This section of the checklist on configuration covers the build, dependency, unintended security disclosure, and HTTP security headers-related requirements.

You can find the full version of the OWASP Application Security Verification Standard checklist for security audits here.

Final Thoughts

For those aiming to enhance the level of their application’s security, it is highly recommended to spare some time and familiarize themselves with the latest version of the Application Security Verification Standard. This document not only helps the security professional but also the developers who could get some serious motivation in order to build security into the product from the start.

With the rising level of threats and the continuing intensity of community efforts, we really believe that the ASVS project will adapt to the changes and keep improving upon itself.