V3.1.1 Web Frontend Security Documentation requirement
Requirement V3.1.1 (Level 3) requires verifying that application documentation states the expected security features that browsers using the application must support, such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms. The documentation must also define how the application must behave when some of these features are not available, such as warning the user or blocking access.
V3.2.1 Unintended Content Interpretation prevention
Requirement V3.2.1 (Level 1) requires verifying that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context, such as when an API, user-uploaded file, or other resource is requested directly. Possible controls include not serving content unless HTTP request header fields such as Sec-Fetch-* indicate correct context, using the sandbox directive of the Content-Security-Policy header field, or using the attachment disposition type in the Content-Disposition header field.
V3.2.2 Safe rendering of text content
Requirement V3.2.2 (Level 1) requires verifying that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions such as createTextNode or textContent to prevent unintended execution of content such as HTML or JavaScript.
V3.2.3 DOM clobbering prevention
Requirement V3.2.3 (Level 3) requires verifying that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation.
V3.3.1 Cookie Secure attribute and prefix requirement
Requirement V3.3.1 (Level 1) requires verifying that cookies have the 'Secure' attribute set, and if the '__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name.
V3.3.2 Cookie SameSite attribute requirement
Requirement V3.3.2 (Level 2) requires verifying that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).
V3.3.3 Cookie __Host- prefix requirement
Requirement V3.3.3 (Level 2) requires verifying that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts.
V3.3.4 Cookie HttpOnly attribute for sensitive values
Requirement V3.3.4 (Level 2) requires verifying that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value must only be transferred to the client via the 'Set-Cookie' header field.
V3.3.5 Cookie size limit
Requirement V3.3.5 (Level 3) requires verifying that when the application writes a cookie, the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie.
V3.4.1 Strict-Transport-Security header requirement
Requirement V3.4.1 (Level 1) requires verifying that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for Level 2 and up, the policy must apply to all subdomains as well.
V3.4.2 CORS Access-Control-Allow-Origin validation
Requirement V3.4.2 (Level 1) requires verifying that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, the response must not include any sensitive information.
V3.4.3 Content-Security-Policy header requirement
Requirement V3.4.3 (Level 2) requires verifying that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For a Level 3 application, a per-response policy with nonces or hashes must be defined.
V3.7.1 Supported and secure client-side technologies
Requirement V3.7.1 (Level 2) requires verifying that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.
V3.4.4 X-Content-Type-Options nosniff header
Requirement V3.4.4 (Level 2) requires verifying that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser.
V3.4.5 Referrer-Policy header requirement
Requirement V3.4.5 (Level 2) requires verifying that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname.
V3.4.6 Content-Security-Policy frame-ancestors directive
Requirement V3.4.6 (Level 2) requires verifying that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. The X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon.
V3.4.7 Content-Security-Policy violation reporting
Requirement V3.4.7 (Level 3) requires verifying that the Content-Security-Policy header field specifies a location to report violations.
V3.4.8 Cross-Origin-Opener-Policy header requirement
Requirement V3.4.8 (Level 3) requires verifying that all HTTP responses that initiate a document rendering (such as responses with Content-Type text/html), include the Cross-Origin-Opener-Policy header field with the same-origin directive or the same-origin-allow-popups directive as required. This prevents attacks that abuse shared access to Window objects, such as tabnabbing and frame counting.
V3.5.1 CSRF protection without CORS preflight
Requirement V3.5.1 (Level 1) requires verifying that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).
V3.5.2 CORS preflight mechanism for sensitive functionality
Requirement V3.5.2 (Level 1) requires verifying that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field.
V3.5.3 HTTP methods for sensitive functionality
Requirement V3.5.3 (Level 1) requires verifying that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as safe such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load such as an image source where this is not expected.
V3.5.4 Separate hostnames for separate applications
Requirement V3.5.4 (Level 2) requires verifying that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies.
V3.5.5 postMessage origin validation
Requirement V3.5.5 (Level 2) requires verifying that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid.
V3.5.6 JSONP functionality disabled
Requirement V3.5.6 (Level 3) requires verifying that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.
V3.5.7 Authorized data excluded from script resources
Requirement V3.5.7 (Level 3) requires verifying that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks.
V3.5.8 Authenticated resource embedding control
Requirement V3.5.8 (Level 3) requires verifying that authenticated resources (such as images, videos, scripts, and other documents) can be loaded or embedded on behalf of the user only when intended. This can be accomplished by strict validation of the Sec-Fetch-* HTTP request header fields to ensure that the request did not originate from an inappropriate cross-origin call, or by setting a restrictive Cross-Origin-Resource-Policy HTTP response header field to instruct the browser to block returned content.
V3.6.1 External resource integrity with SRI
Requirement V3.6.1 (Level 3) requires verifying that client-side assets, such as JavaScript libraries, CSS, or web fonts, are only hosted externally (e.g., on a Content Delivery Network) if the resource is static and versioned and Subresource Integrity (SRI) is used to validate the integrity of the asset. If this is not possible, there should be a documented security decision to justify this for each resource.
V3.7.2 External redirect allowlist
Requirement V3.7.2 (Level 2) requires verifying that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist.
V3.7.3 Redirect notification outside application control
Requirement V3.7.3 (Level 3) requires verifying that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation.
V3.7.4 HSTS public preload list submission
Requirement V3.7.4 (Level 3) requires verifying that the application's top-level domain (e.g., site.tld) is added to the public preload list for HTTP Strict Transport Security (HSTS). This ensures that the use of TLS for the application is built directly into the main browsers, rather than relying only on the Strict-Transport-Security response header field.
V3.7.5 Application behavior when browser lacks security features
Requirement V3.7.5 (Level 3) requires verifying that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features.
ASVS chapter 3 requirements and NIST mappings
ASVS chapter 3 requirements are mapped to NIST sections as follows: 3.1.1 through 3.1.4 cover session management topics with 3.1.3 mapping to NIST 7.1 and others unmapped; 3.2.1 through 3.2.5 with 3.2.1 mapping to NIST 7.1 and others unmapped; 3.3.1 through 3.3.5 with 3.3.5 mapping to NIST 7.2 and others unmapped; 3.4.1 through 3.4.5 with 3.4.1-3.4.4 mapping to NIST 7.1.1 and 3.4.5 unmapped; 3.5.1 through 3.5.6 with 3.5.1 mapping to NIST 7.1.2 and others unmapped; 3.6.1 through 3.6.2 with 3.6.1 mapping to NIST 7.2.1 and 3.6.2 unmapped; 3.7.1 through 3.7.2 unmapped; 3.8.1 through 3.8.5 with 3.8.1 and 3.8.5 mapping to NIST 7.1 and others unmapped.