Clarify use of HTTP verbs and move to V50 (#2481, #2492)

5.0/en/0x21-V13-API.md

@@ -33,7 +33,7 @@ Note: Due to issues with XXE attacks against DTDs, DTD validation should not be
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **13.2.1** | [MOVED TO 13.6.2] | | | | |
+| **13.2.1** | [MOVED TO 50.4.4] | | | | |
 | **13.2.2** | [MODIFIED, MERGED FROM 13.3.1, LEVEL L1 > L3] Verify that structured data objects are validated to ensure they are properly formed, followed by validation of each input field before any processing of that data takes place. This could involve implementing schema validation for formats like JSON and XML. | | | ✓ | 20 |
 | **13.2.3** | [DELETED, MERGED TO 50.4.1] | | | | |
 | **13.2.4** | [DELETED] | | | | |
@@ -71,9 +71,8 @@ GraphQL is becoming more common as a way of creating data rich clients which are
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **13.6.1** | [MODIFIED, MOVED FROM 14.5.1] Verify that the application only responds to HTTP methods in use by the application or by the API (including OPTIONS during preflight requests) and unused methods (e.g., TRACE) are blocked. | ✓ | ✓ | ✓ | 749 |
-| **13.6.2** | [MODIFIED, MOVED FROM 13.2.1] Verify that HTTP requests using the HEAD, OPTIONS, TRACE or GET verb do not modify any backend data structure or perform any state-changing actions. These requests are safe methods and should therefore not have any side effects. | ✓ | ✓ | ✓ | 650 |
-| **13.6.3** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header field when a Transfer-Encoding header field is present, to prevent HTTP Request Smuggling. | | ✓ | ✓ | 444 |
-| **13.6.4** | [ADDED] Verify that any HTTP header field used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | | ✓ | ✓ | 346 |
+| **13.6.2** | [ADDED] Verify that all application components, including load balancers, firewalls, and application servers, comply with RFC 2616 by ignoring the Content-Length header field when a Transfer-Encoding header field is present, to prevent HTTP Request Smuggling. | | ✓ | ✓ | 444 |
+| **13.6.3** | [ADDED] Verify that any HTTP header field used by the application and defined by intermediary devices like load balancers or proxies, such as X-Real-IP and X-Forwarded-*, cannot be overridden by the end-user. | | ✓ | ✓ | 346 |
 
 ## V13.7 HTTP/2
 

5.0/en/0x50-V50-Web-Frontend-Security.md

@@ -58,6 +58,7 @@ The category should contain requirements with ideas:
 | **50.4.1** | [MODIFIED, MOVED FROM 4.2.2, MERGED FROM 13.2.3] Verify that CORS-safelisted requests to sensitive functionality are checked to ensure that they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP headers that are not CORS-safelisted request-headers. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | ✓ | ✓ | ✓ | 352 |
 | **50.4.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.4.3** | [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3] 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 CORS-safelisted request. This may require checking the values of the 'Origin' and 'Content-Type' request headers or using an extra header field that is not CORS-safelisted.| ✓ | ✓ | ✓ | 346 |
+| **50.4.4** | [MODIFIED, MOVED FROM 13.2.1] Verify that calls 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. This is particularly important if the application does not distinguish between URL parameters and message body parameters. | ✓ | ✓ | ✓ | 650 |
 
 ## V50.5 Cross-Site Script Inclusion