With the number of applications in the market touching new heights, security has become a major concern. OWASP stands for Open Web Application Security Project which is a non-profit foundation that produces articles, documentation, methodologies, tools and technologies to improve the security of software. OWASP started publishing free and open resources in view of the rising cyber attacks. 

Applications are the prime target of hackers for data theft and manipulation. A minor security can result in irreparable damage for both enterprises and consumers. Deploying appropriate security measures is of utmost importance as a vast number of applications are subjected to cyber attacks regularly. If we look at the stats, around 43% of the data breach attempts were directed towards web applications. ASVS is one of the key projects of OWASP developed to enhance the security of applications. This article will walk you through OWASP ASVS and its significance for security teams.

OWASP ASVS 

ASVS stands for Application Security Verification Standard. The OWASP ASVS Project contains a list of security requirements for testers, developers, security professionals and consumers. ASVS establishes a framework of security requirements and controls that act as a basis for testing web application technical security controls. 

The purpose of ASVS is to establish a security framework that normalizes the functional and non-functional security controls implemented at different stages of developing and testing web applications. ASVS governs the verification of application security with the use of an open standard. ASVS is an online community effort that helps testers and security professionals to test security controls within the application and controls deployed in the app environment to provide protection against Cross-Site Scripting (XSS) and SQL injection attacks. 

ASVS is developed to fulfill the below-mentioned objectives:

1. To be used as a metric: ASVS can serve as a yardstick for app developers to determine their app’s level of security.
2. To be used as guidance: It also provides guidance regarding the security controls to be implemented so as to effectively meet the requirements.
3. To be used during procurement: It acts as a guideline to specify application security verification requirements in contracts when procuring tools and services. 

Understanding the key differences between ASVS 3.0 and ASVS 4.0

ASVS 4.0 was released in March 2019 after assessing the market and incorporating feedback from industry experts. Let’s quickly understand the major differences between ASVS 3.0 and ASVS 4.0:

1. The latest version of ASVS covers DevSecOps practices and level 0 has been eliminated. 
2. The previous versions had level 0A and 0B for automated tool scan and basic penetration testing respectively while level 1 is the base level testing in the new version. The new version starts with level 1 that also covers more of OWASP Top 10 vulnerabilities than in the previous version.
3. With the new version, it is pooske to cover Level 1 without accessing the application’s source code or documentation.  
4. The new ASVS document is easy to understand compared to the previous version. The requirements are now split up and divided into subchapters. 
5. Version 4 has key vaults and GUIDs included in it. Plus, backups, caches and secondary data storage are new additions in the list of assets to be protected. 
6. There is a new section on Privacy Controls introduced in the ASVS 4.0 version. 
7. The latest version encompasses password replacement and password complexity requirements. It also covers authentication tokens and password managers.  
8. The Business Logic Verification requirements section has been expanded to include Threat Modeling in the new version.

What is new in the ASVS 4.0 version?

The new version has been restructured to make it easy to understand and the longer chapters have been split up into smaller ones. This helps minimize the controls that a developer or team have to comply with. They can skip sections that aren’t applicable to their applications. One of the key additions to the new version is the NIST 800-63-3 Digital Identity Guidelines that covers evidence-based authentication controls. These guidelines outline requirements for agencies implementing digital identity services. The 4.0 version includes CWE mapping which helps tool manufacturers to match their vulnerability assessment results from other tools and previous versions of ASVS. 

The new version contains a security checklist which aids compliance with OWASP Top 10 2017 and the OWASP Proactive Controls 2018. The latest version is also compliant with the PCI DSS 3.2.1 regulation as it includes chapters on buffer overflow, unsafe memory operations and unsafe memory-related compilation flags. While the ASVS was previously focused on server-side controls, it now encompasses all APIs and applications. The new version no longer contains security controls that are outdated or less relevant.

Understanding Application Security Verification Levels

There are three levels of security verification in ASVS designed to enhance security of applications with different security needs. They are as follows:

ASVS Level 1 Basic 

ASVS Level 1 is relevant for applications that don’t deal in sensitive information and are less susceptible to attacks. Every application must adhere to the basic security standards stated in ASVS Level 1. This level outlines security controls that are designed to safeguard against known vulnerabilities. The security measures listed in this level are pen-testable and integration testable. Level 1 is suited for small and medium sized businesses facing no major security risks. 

ASVS Level 2 Standard

Level 2 guidelines are applicable to applications that conduct business-to-business transactions. Following these guidelines will help app developers secure their applications against illegitimate access, injection flaws, validation and authentication errors. ASVS Level 2 Standard ensures that the measures implemented are in line with the vulnerabilities and threats that pose a risk to the application in focus. ASVS Level 2 is recommended by security experts for safeguarding most applications. Testing at this level requires access to source code, documentation, configuration as well as people involved in the development.

ASVS Level 3 Advanced 

Applications that deal in highly sensitive information need to adhere to ASVS Level 3 Advanced. Examples of such applications include healthcare, defense, finance, legal document management apps among others. To meet the requirements of level 3, app developers must embed security layers into the application right from the earlier stages. Plus, all the security efforts must be documented and audited.

An overview of ASVS 4.0 structure

Following are the chapters covered in the ASVS document that contains instructions to meet specific security requirements:

V1: Architecture, Design and Threat Modeling Requirements

The main focus of the first chapter is availability, privacy, confidentiality, integrity and non-repudiation. Additionally, this chapter also emphasizes the relevance of threat modeling for modern security systems. 

V2: Authentication and Verification Requirements

The second chapter of ASVS 4.0 covers more advanced methods of authentication. This chapter has undergone many changes. More secure methods such as hashing and cryptography are discussed in this chapter. 

V3: Session Management Verification Requirements

This chapter highlights the important session management features an application must possess. Following are the features to bear in mind:

• Sessions should be unique for each individual
• Sessions should be suspended if there has been no action/input for a considerable amount of time. 

V4: Access Control Verification Requirements

The guidelines to meet access control requirements for applications are as follows:

• Application should allow access only to users with the requisite credentials 
• Only limited number of users must be assigned specific privileges and roles
• Access control and permission metadata needs to be stored securely to protect against theft and tampering. 

V5: Validation, Sanitation and Encoding Verification Requirements

This chapter focuses on requirements such as establishing a secure pipeline for input validation and output encoding to thwart injection attacks. It also requires the application to check the range and length of input data properly and encode the output data to protect it from malicious actors. 

V6: Stored Cryptography Verification Requirements

The sixth chapter requires the application to meet the following requirements:

• The application should have a secure error handling mechanism
• The cryptographic modules implemented need to be fail-safe
• There should be an efficient number generator in place that aligns with the cryptography of the application
• Cryptographic keys need to be securely stored.

V7: Error Handling and Logging Verification Requirements

The seventh chapter in the document deals with logging and error handling. Applications should avoid collecting sensitive user information unless absolutely essential. The logged data should be secured in adherence with the prescribed standards and data collected should be deleted after a certain period of time. 

V8: Data Protection Verification Requirements

Confidentiality, availability and integrity are the prime areas of focus in this chapter. Data confidentiality should be maintained at all times (storage and transit). Data must also be protected from manipulation and deletion while ensuring it remains accessible to legitimate users. 

V9: Communication Verification Requirements

This chapter stresses the importance of using encryption and transport layer security at all times. App developers must make use of advanced algorithms rather than relying on weak and outdated ones. Developers should make it a point to replace weaker ciphers and algorithms from time to time to maintain optimal performance and security. 

V10: Malicious Code Verification Requirements

This chapter highlights the importance of managing malicious activities without letting it affect the entire application. The application must be free of elements such as rootkits, time bombs or other such harmful elements that can be exploited by hackers. 

V11: Business Logic Verification Requirements

The application should meet the following business logic verification requirements according to this chapter:

• The business logic should be built with tight security making it difficult for hackers to evade it.
• The business logic should be sequential
• It should be capable of detecting attacks and mitigating them
• Security flaws like tampering and spoofing need to be addressed effectively

V12: File and Resources Verification Requirements

The twelfth chapter specifies that applications should have a secure and compliant mechanism to manage data from unknown sources. It also mandates limited permissions for data collected from untrusted sources. Such data should always be stored outside the webroot. 

V13: API and Web Service Verification Requirements

This chapter is about the APIs of the application. The following requirements need to be fulfilled:

• It is mandatory for APIs to have session management parameters. There must be a proper authentication in place to access the web services. 
• There should be proper input validation if the parameters shift from lower to higher trust levels. 
• Requisite security controls need to be implemented while dealing with cloud and serverless APIs. 

V14: Configuration and Verification Requirements

This chapter deals with the configuration requirements which state that the application environment must always be safeguarded against vulnerabilities. App developers must monitor third-party libraries and also implement a configuration and dependency management system to remove components that pose a risk to application security. 

OWASP ASVS Checklist for Security Audit

Let’s have a look at the different sections covered in the checklist for security audits. 

Architecture:

This section covers a broad range of security requirements. From threat modeling verification to analyzing the access control mechanisms of the application, the architecture section aids in verification of application’s trust boundaries. 

Authentication:

This checklist deals with authentication requirements that include verification of credentials, secure storage of credentials and verification of authentication pathways and identity management APIs. It covers Password Security Requirements, General Authenticator Requirements, Authenticator Lifecycle Requirements, Credential Storage Requirements, Credential Recovery Requirements, Look-up Secret Verifier Requirements, Out of Band Verifier Requirements, Single or Multi Factor One Time Verifier Requirements, Cryptographic Software and Devices Verifier Requirements and Service Authentication Requirements.

Session Management:

This checklist outlines the requirements to be met for managing session logout and timeout. It also includes cookie-based and token-based session management along with defenses against session management exploits.

Access Control:

Access control should be enforced at servers, access control gateways, and serverless functions. The access control should be flexible enough to meet the application’s needs. This list covers general access control design, operation level access control and other access control considerations. 

Input Validation:

Input and output requirements need to be verified to ensure they define data processing techniques based on the type, content and applicable laws. The checklist includes everything from input validation requirements to deserialization prevention requirements. 

Cryptography at Rest:

This checklist stresses the importance of having a strong cryptographic architecture. The storage of cryptographic keys should be managed properly. Keys and passwords need to be replaceable and symmetric keys shared with clients should be used only to protect low-risk data. Data classification, algorithms, random values and secret management are the prime areas of focus in this section

Error handling and logging:

This section primarily deals with verification of log content and requirements for log processing and log protection along with error handling. 

Data protection:

Sensitive data needs to be categorized into different protection levels as mentioned in this portion of the checklist. This section also covers guidelines related to protection of client side and general data. 

Communication Security:

This checklist that includes server communication security requirements states that applications need to encrypt all communications between components. All the components involved in the communication need to be secured to avoid person-in-the-middle attacks. Only trusted TLS certificates must be used.

Malicious Code:

This section deals with verification of code analysis tools. Malicious code search, code integrity controls and application integrity controls come under the ambit of this section.

Business Logic:

This section entails all business logic security requirements that will secure the application from external threats. 

Files and Resources:

This section highlights the requirements to be fulfilled for secure upload of files. It covers file upload requirements, file integrity requirements, file storage requirements, file download requirements and SSRF protection requirements. 

Web service:

This section provides requirements related to RESTful web service verification, SOAP web service verification, Generic web service security, and GraphQL and other Web Service Data Layer Security Requirements.

Configuration:

This checklist entails build, dependency, requirements related to HTTP security headers and unintended security disclosure. 

Final Thoughts

OWASP ASVS offers a more comprehensive testing coverage enabling developers and security teams to conduct a thorough web application security assessment. There are three levels of ASVS standard with each level designed to cater to different security requirements depending on the nature of the application. Adhering to ASVS standards will greatly enhance the security of applications. Given the rise in cyberattacks these days, using ASVS is recommended for every organization to maintain credibility and reputation in the market. Following the security guidelines listed in OWASP ASVS proves that the organization prioritizes security. 

The proliferation of application vulnerabilities has made it essential for enterprises to conduct a comprehensive assessment of web applications and OWASP ASVS serves as a perfect guide for development teams to tighten application security. ASVS can be used as a yardstick to assess applications’ trust. It includes 286 controls and enables security service providers to offer standardized and repeatable services by using ASVS as a basis for testing. Aligning development and assessment activities with the appropriate ASVS level will save your enterprise from costly fixes in the future. 

Appsealing is a robust mobile application security solutions provider that specializes in the security of Android, iOS, and Hybrid apps. With expertise spanning across industries such as gaming, fintech, O2O and e-commerce, we offer in-app, scalable protection with threat analytics on attack vectors. Characterized by zero coding features, our security solutions are compatible with third-party tools and facilitate the protection of sensitive data from data theft, tampering and unauthorized access. Contact us and leverage our security solutions today to protect your application from malicious actors.