Clarify tags from 13.2.3

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

@@ -35,7 +35,7 @@ Note: Due to issues with XXE attacks against DTDs, DTD validation should not be
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **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.3** | [DELETED, COVERED BY 50.4.1, 50.4.3] | | | | |
 | **13.2.4** | [DELETED] | | | | |
 | **13.2.5** | [MOVED TO 50.4.3] | | | | |
 | **13.2.6** | [MOVED TO 13.1.6] | | | | |

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

@@ -57,9 +57,9 @@ The category should contain requirements with ideas:
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **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.1** | [MODIFIED, MOVED FROM 4.2.2, COVERS 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.3** | [MODIFIED, MOVED FROM 13.2.5, SPLIT FROM 14.5.3, COVERS 13.2.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