diff --git a/5.0/en/0x50-V50-Web-Frontend-Security.md b/5.0/en/0x50-V50-Web-Frontend-Security.md index 5ad0ed731a..b00ad11130 100644 --- a/5.0/en/0x50-V50-Web-Frontend-Security.md +++ b/5.0/en/0x50-V50-Web-Frontend-Security.md @@ -12,7 +12,7 @@ The category focuses on requirements that protect against attacks that are execu | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **50.1.1** | [ADDED, DEPRECATES 3.4.5] Verify that separate applications are hosted on different hostnames to benefit from the restrictions provided by the "same-origin policy" including how documents or scripts loaded by one origin can interact with resources from another origin and hostname restrictions on cookies. | ✓ | ✓ | ✓ | 668 | +| **50.1.1** | [ADDED, DEPRECATES 3.4.5] 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. | ✓ | ✓ | ✓ | 668 | ## V50.2 Browser Security Mechanism Headers @@ -21,11 +21,11 @@ The category focuses on requirements that protect against attacks that are execu | **50.2.1** | [MODIFIED, MOVED FROM 14.4.3] Verify that every HTTP response includes a Content-Security-Policy header to reduce the risk of malicious JavaScript. The directives object-src 'none' and base-uri 'none' must be defined. For an L3 application, a per-response policy with nonces or hashes must be defined. | | ✓ | ✓ | | | **50.2.2** | [GRAMMAR, MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header field. | ✓ | ✓ | ✓ | 116 | | **50.2.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header field is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | ✓ | ✓ | ✓ | 523 | -| **50.2.4** | [GRAMMAR, MOVED FROM 14.4.6] Verify that a suitable Referrer-Policy header field is included to avoid exposing sensitive information in the URL through the Referer header field to untrusted parties. | ✓ | ✓ | ✓ | 116 | -| **50.2.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors. Note that the X-Frame-Options solution is obsoleted. | ✓ | ✓ | ✓ | 1021 | -| **50.2.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field uses a strict allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 | +| **50.2.4** | [GRAMMAR, MOVED FROM 14.4.6] Verify that an suitable Referrer-Policy header is included to prevent sensitive information in the URL from being exposed to untrusted parties via the Referer header. | ✓ | ✓ | ✓ | 116 | +| **50.2.5** | [MODIFIED, MOVED FROM 14.4.7] Verify that the content of the web application cannot be embedded in a third-party site by default, and that embedding of specific resources is allowed only when necessary, using the Content-Security-Policy frame-ancestors directive. Note that X-Frame-Options is now obsolete. | ✓ | ✓ | ✓ | 1021 | +| **50.2.6** | [ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is validated against an allowlist of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information. | ✓ | ✓ | ✓ | 183 | | **50.2.7** | [ADDED] Verify that the Content-Security-Policy header field specifies a location to report violations. | | | ✓ | | -| **50.2.8** | [ADDED] Verify that the application's top-level domain (e.g. site.tld) is added to the public HSTS preload list so that the use of TLS for the application will be built directly into the main browsers rather than only relying on the relevant HTTP response header field. | | | ✓ | | +| **50.2.8** | [ADDED] Verify that the application's top-level domain (e.g., site.tld) is added to the public HSTS preload list so that the use of TLS for the application is built directly into the main browsers, rather than relying only on the relevant HTTP response header field. | | | ✓ | | ## V50.3 Browser Origin Separation @@ -40,7 +40,7 @@ The category should contain requirements with ideas: | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | -| **50.3.1** | [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality using the development framework's built-in anti-CSRF functionality or CSRF tokens plus additional defense in depth measures. | ✓ | ✓ | ✓ | 352 | +| **50.3.1** | [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality, using the development framework's built-in anti-CSRF functionality or CSRF tokens, along with additional defense-in-depth measures. | ✓ | ✓ | ✓ | 352 | | **50.3.2** | [ADDED] 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. | | ✓ | ✓ | 346 | | **50.3.3** | [ADDED, SPLIT FROM 14.5.3] Verify that the Origin header field is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy. | ✓ | ✓ | ✓ | 346 | @@ -56,7 +56,7 @@ The category should contain requirements with ideas: | # | Description | L1 | L2 | L3 | CWE | | :---: | :--- | :---: | :---: | :---: | :---: | | **50.5.1** | [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] 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, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc. | ✓ | ✓ | ✓ | | -| **50.5.2** | [ADDED, SPLIT FROM 5.3.3] Verify that context-aware methods are used when handling untrusted data to avoid unintended content execution, such as executing content as HTML instead of displaying it as text. | ✓ | ✓ | ✓ | | +| **50.5.2** | [ADDED, SPLIT FROM 5.3.3] Verify that JavaScript context-aware methods are used when handling untrusted data to avoid unintended content execution, such as executing content as HTML instead of displaying it as text. | ✓ | ✓ | ✓ | | ## V50.6 External Resource Integrity