OWASP Application Security Verification Standard 5.0.0

Control Objective

This chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter.

For modern web applications, it is always best to use safer APIs, such as parameterized queries, auto-escaping, or templating frameworks. Otherwise, carefully performed output encoding, escaping, or sanitization becomes critical to the application's security.

Input validation serves as a defense-in-depth mechanism to protect against unexpected or dangerous content. However, since its primary purpose is to ensure that incoming content matches functional and business expectations, requirements related to this can be found in the "Validation and Business Logic" chapter.

References

For more information, see also:

• OWASP LDAP Injection Prevention Cheat Sheet
• OWASP Cross Site Scripting Prevention Cheat Sheet
• OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet
• OWASP XML External Entity Prevention Cheat Sheet
• OWASP Web Security Testing Guide: Client-Side Testing
• OWASP Java Encoding Project
• DOMPurify - Client-side HTML Sanitization Library
• RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files

For more information, specifically on deserialization or parsing issues, please see:

• OWASP Deserialization Cheat Sheet
• An Exploration of JSON Interoperability Vulnerabilities
• Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages

Control Objective

This chapter aims to ensure that a verified application meets the following high-level goals:

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

References

For more information, see also:

• OWASP Web Security Testing Guide: Input Validation Testing
• OWASP Web Security Testing Guide: Business Logic Testing
• Anti-automation can be achieved in many ways, including the use of the OWASP Automated Threats to Web Applications
• OWASP Input Validation Cheat Sheet
• JSON Schema

Control Objective

This category focuses on requirements designed to protect against attacks executed via a web frontend. These requirements do not apply to machine-to-machine solutions.

References

For more information, see also:

• Set-Cookie __Host- prefix details
• OWASP Content Security Policy Cheat Sheet
• OWASP Secure Headers Project
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet
• HSTS Browser Preload List submission form
• OWASP DOM Clobbering Prevention Cheat Sheet

Control Objective

Several considerations apply specifically to applications that expose APIs for use by web browsers or other consumers (commonly using JSON, XML, or GraphQL). This chapter covers the relevant security configurations and mechanisms that should be applied.

Note that authentication, session management, and input validation concerns from other chapters also apply to APIs, so this chapter cannot be taken out of context or tested in isolation.

References

For more information, see also:

• OWASP REST Security Cheat Sheet
• Resources on GraphQL Authorization from graphql.org and Apollo.
• OWASP Web Security Testing Guide: GraphQL Testing
• OWASP Web Security Testing Guide: Testing WebSockets

Control Objective

The use of files can present a variety of risks to the application, including denial of service, unauthorized access, and storage exhaustion. This chapter includes requirements to address these risks.

References

For more information, see also:

• OWASP File Upload Cheat Sheet
• Example of using symlinks for arbitrary file read
• Explanation of "Magic Bytes" from Wikipedia

Control Objective

Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords.

NIST SP 800-63 is a modern, evidence-based standard that is valuable for organizations worldwide, but is particularly relevant to US agencies and those interacting with US agencies.

While many of the requirements in this chapter are based on the second section of the standard (known as NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management"), the chapter focuses on common threats and frequently exploited authentication weaknesses. It does not attempt to comprehensively cover every point in the standard. For cases where full NIST SP 800-63 compliance is necessary, please refer to NIST SP 800-63.

Additionally, NIST SP 800-63 terminology may sometimes differ, and this chapter often uses more commonly understood terminology to improve clarity.

A common feature of more advanced applications is the ability to adapt authentication stages required based on various risk factors. This feature is covered in the "Authorization" chapter, since these mechanisms also need to be considered for authorization decisions.

References

For more information, see also:

• NIST SP 800-63 - Digital Identity Guidelines
• NIST SP 800-63B - Authentication and Lifecycle Management
• NIST SP 800-63 FAQ
• OWASP Web Security Testing Guide: Testing for Authentication
• OWASP Password Storage Cheat Sheet
• OWASP Forgot Password Cheat Sheet
• OWASP Choosing and Using Security Questions Cheat Sheet
• CISA Guidance on "Number Matching"
• Details on the FIDO Alliance

Control Objective

Session management mechanisms allow applications to correlate user and device interactions over time, even when using stateless communication protocols (such as HTTP). Modern applications may use multiple session tokens with distinct characteristics and purposes. A secure session management system is one that prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. Applications maintaining sessions must ensure that the following high-level session management requirements are met:

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

Many of the requirements in this chapter relate to selected NIST SP 800-63 Digital Identity Guidelines controls, focusing on common threats and commonly exploited authentication weaknesses.

Note that requirements for specific implementation details of certain session management mechanisms can be found elsewhere:

• HTTP Cookies are a common mechanism for securing session tokens. Specific security requirements for cookies can be found in the "Web Frontend Security" chapter.
• Self-contained tokens are frequently used as a way of maintaining sessions. Specific security requirements can be found in the "Self-contained Tokens" chapter.

References

For more information, see also:

• OWASP Web Security Testing Guide: Session Management Testing
• OWASP Session Management Cheat Sheet

Control Objective

Authorization ensures that access is granted only to permitted consumers (users, servers, and other clients). To enforce the Principle of Least Privilege (POLP), verified applications must meet the following high-level requirements:

• Document authorization rules, including decision-making factors and environmental contexts.
• Consumers should have access only to resources permitted by their defined entitlements.

References

For more information, see also:

• OWASP Web Security Testing Guide: Authorization
• OWASP Authorization Cheat Sheet

Control Objective

The concept of a self-contained token is mentioned in the original RFC 6749 OAuth 2.0 from 2012. It refers to a token containing data or claims on which a receiving service will rely to make security decisions. This should be differentiated from a simple token containing only an identifier, which a receiving service uses to look up data locally. The most common examples of self-contained tokens are JSON Web Tokens (JWTs) and SAML assertions.

The use of self-contained tokens has become very widespread, even outside of OAuth and OIDC. At the same time, the security of this mechanism relies on the ability to validate the integrity of the token and to ensure that the token is valid for a particular context. There are many pitfalls with this process, and this chapter provides specific details of the mechanisms that applications should have in place to prevent them.

References

For more information, see also:

• OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet (but has useful general guidance)

Control Objective

OAuth2 (referred to as OAuth in this chapter) is an industry-standard framework for delegated authorization. For example, using OAuth, a client application can obtain access to APIs (server resources) on a user's behalf, provided the user has authorized the client application to do so.

By itself, OAuth is not designed for user authentication. The OpenID Connect (OIDC) framework extends OAuth by adding a user identity layer on top of OAuth. OIDC provides support for features including standardized user information, Single Sign-On (SSO), and session management. As OIDC is an extension of OAuth, the OAuth requirements in this chapter also apply to OIDC.

The following roles are defined in OAuth:

• The OAuth client is the application that attempts to obtain access to server resources (e.g., by calling an API using the issued access token). The OAuth client is often a server-side application.
• A confidential client is a client capable of maintaining the confidentiality of the credentials it uses to authenticate itself with the authorization server.
• A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter).
• The OAuth resource server (RS) is the server API exposing resources to OAuth clients.
• The OAuth authorization server (AS) is a server application that issues access tokens to OAuth clients. These access tokens allow OAuth clients to access RS resources, either on behalf of an end-user or on the OAuth client's own behalf. The AS is often a separate application, but (if appropriate) it may be integrated into a suitable RS.
• The resource owner (RO) is the end-user who authorizes OAuth clients to obtain limited access to resources hosted on the resource server on their behalf. The resource owner consents to this delegated authorization by interacting with the authorization server.

The following roles are defined in OIDC:

• The relying party (RP) is the client application requesting end-user authentication through the OpenID Provider. It assumes the role of an OAuth client.
• The OpenID Provider (OP) is an OAuth AS that is capable of authenticating the end-user and provides OIDC claims to an RP. The OP may be the identity provider (IdP), but in federated scenarios, the OP and the identity provider (where the end-user authenticates) may be different server applications.

OAuth and OIDC were initially designed for third-party applications. Today, they are often used by first-party applications as well. However, when used in first-party scenarios, such as authentication and session management, the protocol adds some complexity, which may introduce new security challenges.

OAuth and OIDC can be used for many types of applications, but the focus for ASVS and the requirements in this chapter is on web applications and APIs.

Since OAuth and OIDC can be considered logic on top of web technologies, general requirements from other chapters always apply, and this chapter cannot be taken out of context.

This chapter addresses best current practices for OAuth2 and OIDC aligned with specifications found at https://oauth.net/2/ and https://openid.net/developers/specs/. Even if RFCs are considered mature, they are updated frequently. Thus, it is important to align with the latest versions when applying the requirements in this chapter. See the references section for more details.

Given the complexity of the area, it is vitally important for a secure OAuth or OIDC solution to use well-known industry-standard authorization servers and apply the recommended security configuration.

Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements; otherwise, OAuth terminology is used.

In the context of OAuth and OIDC, the term "token" in this chapter refers to:

• Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection or self-contained tokens that are validated using some key material.
• Refresh tokens, which shall only be consumed by the authorization server that issued the token.
• OIDC ID Tokens, which shall only be consumed by the client that triggered the authorization flow.

The risk levels for some of the requirements in this chapter depend on whether the client is a confidential client or regarded as a public client. Since using strong client authentication mitigates many attack vectors, a few requirements might be relaxed when using a confidential client for L1 applications.

References

For more information on OAuth, please see:

• oauth.net
• OWASP OAuth 2.0 Protocol Cheat Sheet

For OAuth-related requirements in ASVS following published and in draft status RFC-s are used:

• RFC6749 The OAuth 2.0 Authorization Framework
• RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC6819 OAuth 2.0 Threat Model and Security Considerations
• RFC7636 Proof Key for Code Exchange by OAuth Public Clients
• RFC7591 OAuth 2.0 Dynamic Client Registration Protocol
• RFC8628 OAuth 2.0 Device Authorization Grant
• RFC8707 Resource Indicators for OAuth 2.0
• RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
• RFC9126 OAuth 2.0 Pushed Authorization Requests
• RFC9207 OAuth 2.0 Authorization Server Issuer Identification
• RFC9396 OAuth 2.0 Rich Authorization Requests
• RFC9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• RFC9700 Best Current Practice for OAuth 2.0 Security
• draft OAuth 2.0 for Browser-Based Applications
• draft The OAuth 2.1 Authorization Framework

For more information on OpenID Connect, please see:

• OpenID Connect Core 1.0
• FAPI 2.0 Security Profile

Control Objective

The objective of this chapter is to define best practices for the general use of cryptography, as well as to instill a fundamental understanding of cryptographic principles and inspire a shift toward more resilient and modern approaches. It encourages the following:

• Implementing robust cryptographic systems that fail securely, adapt to evolving threats, and are future-proof.
• Utilizing cryptographic mechanisms that are both secure and aligned with industry best practices.
• Maintaining a secure cryptographic key management system with appropriate access controls and auditing.
• Regularly evaluating the cryptographic landscape to assess new risks and adapt algorithms accordingly.
• Discovering and managing cryptographic use cases throughout the application's lifecycle to ensure that all cryptographic assets are accounted for and secured.

In addition to outlining general principles and best practices, this document also provides more in-depth technical information about the requirements in Appendix C - Cryptography Standards. This includes algorithms and modes that are considered "approved" for the purposes of the requirements in this chapter.

Requirements that use cryptography to solve a separate problem, such as secrets management or communications security, will be in different parts of the standard.

References

For more information, see also:

• OWASP Web Security Testing Guide: Testing for Weak Cryptography
• OWASP Cryptographic Storage Cheat Sheet
• FIPS 140-3
• NIST SP 800-57

Control Objective

This chapter includes requirements related to the specific mechanisms that should be in place to protect data in transit, both between an end-user client and a backend service, as well as between internal and backend services.

The general concepts promoted by this chapter include:

• Ensuring that communications are encrypted externally, and ideally internally as well.
• Configuring encryption mechanisms using the latest guidance, including preferred algorithms and ciphers.
• Ensuring that communications are not being intercepted by unauthorized parties through the use of signed certificates.

In addition to outlining general principles and best practices, the ASVS also provides more in-depth technical information about cryptographic strength in Appendix C - Cryptography Standards.

References

For more information, see also:

• OWASP - Transport Layer Security Cheat Sheet
• Mozilla's Server Side TLS configuration guide
• Mozilla's tool to generate known good TLS configurations.
• O-Saft - OWASP Project to validate TLS configuration

Control Objective

The application's default configuration must be secure for use on the Internet.

This chapter provides guidance on the various configurations necessary to achieve this, including those applied during development, build, and deployment.

Topics covered include preventing data leakage, securely managing communication between components, and protecting secrets.

References

For more information, see also:

• OWASP Web Security Testing Guide: Configuration and Deployment Management Testing

Control Objective

Applications cannot account for all usage patterns and user behaviors, and should therefore implement controls to limit unauthorized access to sensitive data on client devices.

This chapter includes requirements related to defining what data needs to be protected, how it should be protected, and specific mechanisms to implement or pitfalls to avoid.

Another consideration for data protection is bulk extraction, modification, or excessive usage. Each system's requirements are likely to be very different, so determining what is "abnormal" must consider the threat model and business risk. From an ASVS perspective, detecting these issues is handled in the "Security Logging and Error Handling" chapter, and setting limits is handled in the "Validation and Business Logic" chapter.

References

For more information, see also:

• Consider using the Security Headers website to check security and anti-caching header fields
• Documentation about anti-caching headers by Mozilla
• OWASP Secure Headers project
• OWASP Privacy Risks Project
• OWASP User Privacy Protection Cheat Sheet
• Australian Privacy Principle 11 - Security of personal information
• European Union General Data Protection Regulation (GDPR) overview
• European Union Data Protection Supervisor - Internet Privacy Engineering Network
• Information on the "Clear-Site-Data" header
• White paper on Web Cache Deception

Control Objective

Many ASVS requirements either relate to a particular area of security, such as authentication or authorization, or pertain to a particular type of application functionality, such as logging or file handling.

This chapter provides general security requirements to consider when designing and developing applications. These requirements focus not only on clean architecture and code quality but also on specific architecture and coding practices necessary for application security.

References

For more information, see also:

• OWASP Prototype Pollution Prevention Cheat Sheet
• OWASP Mass Assignment Prevention Cheat Sheet
• OWASP CycloneDX Bill of Materials Specification
• OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution

Control Objective

Security logs are distinct from error or performance logs and are used to record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls, such as input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs.

Logs should not include sensitive personal data unless legally required, and any logged data must be protected as a high-value asset. Logging must not compromise privacy or system security. Applications must also fail securely, avoiding unnecessary disclosure or disruption.

For detailed implementation guidance, refer to the OWASP Cheat Sheets in the references section.

References

For more information, see also:

• OWASP Web Security Testing Guide: Testing for Error Handling
• OWASP Authentication Cheat Sheet section about error messages
• OWASP Logging Cheat Sheet
• OWASP Application Logging Vocabulary Cheat Sheet

Control Objective

Web Real-Time Communication (WebRTC) enables real-time voice, video, and data exchange in modern applications. As adoption increases, securing WebRTC infrastructure becomes critical. This section provides security requirements for stakeholders who develop, host, or integrate WebRTC systems.

The WebRTC market can be broadly categorized into three segments:

1. Product Developers: Proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others.

1. Communication Platforms as a Service (CPaaS): Providers that offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services.

1. Service Providers: Organizations that leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial.

The security requirements outlined here are primarily focused on Product Developers, CPaaS, and Service Providers who:

• Utilize open-source solutions to build their WebRTC applications.
• Use commercial WebRTC products as part of their infrastructure.
• Use internally developed WebRTC solutions or integrate various components into a cohesive service offering.

It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs.

References

For more information, see also:

• The WebRTC DTLS ClientHello DoS is best documented at Enable Security's blog post aimed at security professionals and the associated white paper aimed at WebRTC developers
• RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
• RFC 3711 - The Secure Real-time Transport Protocol (SRTP)
• RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP))
• RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications
• RFC 8826 - Security Considerations for WebRTC
• RFC 8827 - WebRTC Security Architecture
• DTLS-SRTP Protection Profiles