ASVS 5.0 V3 Web Frontend Security

V3.1 Web Frontend Security Documentation · 1 requirement

1. V3.1.1 Level 3

   Verify 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). It 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 Unintended Content Interpretation · 3 requirements

For the whole section: Prevent DOM XSS, postMessage abuse and client-side injection (guide)

1. V3.2.1 Level 1

   Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-\*) indicate it is the 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.

   On this site: Unrestricted file upload (fix card)

2. V3.2.2 Level 1

   Verify 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.

   On this site: Prevent XSS at the output boundary (guide) · Render rich text without granting it application privileges (guide) · Keep generated output out of executable contexts (guide)

3. V3.2.3 Level 3

   Verify 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.

   On this site: Render rich text without granting it application privileges (guide)

V3.3 Cookie Setup · 5 requirements

1. V3.3.1 Level 1

   Verify 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.

   On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Preserve framework security controls across the request lifecycle (guide) · Session fixation and session cookies (fix card)

2. V3.3.2 Level 2

   Verify 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).

   On this site: Protect cookie-authenticated actions against CSRF (guide) · Cross-site request forgery (CSRF) (fix card) · Session fixation and session cookies (fix card)

3. V3.3.3 Level 2

   Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts.

   On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Protect cookie-authenticated actions against CSRF (guide) · Prevent subdomain takeover from dangling DNS records (guide) · Session fixation and session cookies (fix card)

4. V3.3.4 Level 2

   Verify 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 (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field.

   On this site: Session fixation and session cookies (fix card)

5. V3.3.5 Level 3

   Verify 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 Browser Security Mechanism Headers · 8 requirements

1. V3.4.1 Level 1

   Verify 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 L2 and up, the policy must apply to all subdomains as well.

   On this site: Preserve framework security controls across the request lifecycle (guide) · Operate TLS and certificates: configuration, renewal and verification (guide)

2. V3.4.2 Level 1

   Verify 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, verify that the response does not include any sensitive information.

   On this site: Configure CORS and CSP around the browser capabilities you need (guide) · Prevent subdomain takeover from dangling DNS records (guide) · CORS misconfiguration on credentialed APIs (fix card)

3. V3.4.3 Level 2

   Verify 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 an L3 application, a per-response policy with nonces or hashes must be defined.

   On this site: Configure CORS and CSP around the browser capabilities you need (guide) · Preserve framework security controls across the request lifecycle (guide)

4. V3.4.4 Level 2

   Verify 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.

   On this site: Unrestricted file upload (fix card)

5. V3.4.5 Level 2

   Verify 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.

6. V3.4.6 Level 2

   Verify 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. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon.

   On this site: Configure CORS and CSP around the browser capabilities you need (guide) · Clickjacking (fix card)

7. V3.4.7 Level 3

   Verify that the Content-Security-Policy header field specifies a location to report violations.

   On this site: Configure CORS and CSP around the browser capabilities you need (guide)

8. V3.4.8 Level 3

   Verify 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 Browser Origin Separation · 8 requirements

For the whole section: Prevent DOM XSS, postMessage abuse and client-side injection (guide)

1. V3.5.1 Level 1

   Verify 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).

   On this site: Protect cookie-authenticated actions against CSRF (guide) · Cross-site request forgery (CSRF) (fix card)

2. V3.5.2 Level 1

   Verify 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.

   On this site: Protect cookie-authenticated actions against CSRF (guide) · Configure CORS and CSP around the browser capabilities you need (guide) · CORS misconfiguration on credentialed APIs (fix card)

3. V3.5.3 Level 1

   Verify 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.

   On this site: Protect cookie-authenticated actions against CSRF (guide) · Cross-site request forgery (CSRF) (fix card)

4. V3.5.4 Level 2

   Verify 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.

5. V3.5.5 Level 2

   Verify 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.

   On this site: Render rich text without granting it application privileges (guide)

6. V3.5.6 Level 3

   Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.

7. V3.5.7 Level 3

   Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks.

8. V3.5.8 Level 3

   Verify 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 External Resource Integrity · 1 requirement

For the whole section: Map PCI DSS Requirement 6 to engineering practice and evidence (guide)

1. V3.6.1 Level 3

   Verify 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 Other Browser Security Considerations · 5 requirements

1. V3.7.1 Level 2

   Verify 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.

2. V3.7.2 Level 2

   Verify 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.

   On this site: Open redirect (fix card)

3. V3.7.3 Level 3

   Verify 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.

4. V3.7.4 Level 3

   Verify 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.

5. V3.7.5 Level 3

   Verify 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.