mapping fixes, resolve #2454

5.0/en/0x12-V3-Session-management.md

@@ -74,7 +74,7 @@ Some of the requirements in this section relate to section [7.2](https://pages.n
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **3.5.1** | [MOVED TO 51.2.14] | | | | |
+| **3.5.1** | [MOVED TO 51.4.14] | | | | |
 | **3.5.2** | [MOVED TO 3.1.3] | | | | |
 | **3.5.3** | [MOVED TO 52.1.1] | | | | |
 

5.0/en/0x12-V4-Access-Control.md

@@ -43,7 +43,7 @@ The immediate application of access control changes in the appropriate tier of a
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **4.2.1** | [MOVED TO 4.1.6] | | | | |
-| **4.2.2** | [MOVED TO 50.3.1] | | | | |
+| **4.2.2** | [MOVED TO 50.4.1] | | | | |
 | **4.2.3** | [MODIFIED, MOVED FROM 4.1.1] Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | ✓ | ✓ | ✓ | 602 |
 | **4.2.4** | [ADDED] Verify that changes to values on which access control decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they should no longer be able to do so and revert the change. Note that this would be unable to mitigate information leakage. | | ✓ | ✓ | |
 | **4.2.5** | [ADDED] Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service should use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | | | ✓ | 441 |

5.0/en/0x13-V5-Validation-Sanitization-Encoding.md

@@ -38,7 +38,7 @@ Input validation provides valuable hygiene for the application in making sure th
 | **5.1.2** | [MOVED TO 10.4.4] | | | | |
 | **5.1.3** | [MODIFIED] Verify that all input is validated using positive validation, against an allowed list of values, patterns or ranges to enforce business or functional expectations for that input. | ✓ | ✓ | ✓ | 20 |
 | **5.1.4** | [MODIFIED, SPLIT TO 5.1.7] Verify that data items with an expected structure are validated according to the pre-defined rules. | ✓ | ✓ | ✓ | 20 |
-| **5.1.5** | [MODIFIED, SPLIT TO 50.7.1] Verify that the application will only automatically redirect the user to a different URL directly from an application URL where the destination appears on an allowlist. | ✓ | ✓ | ✓ | 601 |
+| **5.1.5** | [MODIFIED, SPLIT TO 50.8.1] Verify that the application will only automatically redirect the user to a different URL directly from an application URL where the destination appears on an allowlist. | ✓ | ✓ | ✓ | 601 |
 | **5.1.6** | [ADDED] Verify that untrusted input is validated for length before being included in a cookie (including as part of a JWT) and that the cookie name and value length combined are not over 4096 bytes. | | ✓ | ✓ | |
 | **5.1.7** | [ADDED, SPLIT FROM 5.1.4] Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | ✓ | ✓ | ✓ | 20 |
 | **5.1.8** | [ADDED] Verify that the application validates that user-controlled input in HTTP request header fields does not exceed the server's maximum header field size limit (usually 4kB or 8kB) to prevent client-based denial of service attacks. | | ✓ | ✓ | |
@@ -77,7 +77,7 @@ In many cases, software libraries will include safe or safer functions which wil
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **5.3.1** | [MODIFIED, SPLIT TO 5.3.13] Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | ✓ | ✓ | ✓ | 116 |
 | **5.3.2** | [DELETED, DUPLICATE OF 14.4.1] | | | | |
-| **5.3.3** | [MODIFIED, SPLIT TO 50.5.2] Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | ✓ | ✓ | ✓ | |
+| **5.3.3** | [MODIFIED, SPLIT TO 50.6.2] Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | ✓ | ✓ | ✓ | |
 | **5.3.4** | [MODIFIED] Verify that data selection or database queries (e.g. SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This should also be considered when writing stored procedures. | ✓ | ✓ | ✓ | 89 |
 | **5.3.5** | [DELETED, DUPLICATE OF 5.3.4] | | | | |
 | **5.3.6** | [DELETED, DUPLICATE OF 5.3.3] | | | | |

5.0/en/0x14-V6-Cryptography.md

@@ -49,7 +49,7 @@ Although this section is not easily penetration tested, developers should consid
 | **6.2.1** | [MODIFIED] Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | ✓ | ✓ | ✓ | 310 |
 | **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | | ✓ | ✓ | 327 |
 | **6.2.3** | [DELETED, DUPLICATE OF 6.2.5] | | | | |
-| **6.2.4** | [MODIFIED] Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
+| **6.2.4** | [MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
 | **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.3] | | | | |
 | **6.2.6** | [MOVED TO 6.5.3] | | | | |
 | **6.2.7** | [MOVED TO 6.5.4] | | | | |

5.0/en/0x20-V12-Files-Resources.md

@@ -9,7 +9,7 @@ Ensure that untrusted files and other resources are handled safely to prevent de
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **1.12.1** | [DELETED, DUPLICATE OF 12.4.1] | | | | |
-| **1.12.2** | [DELETED, MERGED TO 50.5.1] | | | | |
+| **1.12.2** | [DELETED, MERGED TO 50.6.1] | | | | |
 | **1.12.3** | [ADDED] Verify that, if the application allows uploading files, the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process. | ✓ | ✓ | ✓ | |
 
 ## V12.1 File Upload
@@ -62,7 +62,7 @@ User-submitted filenames should be validated or ignored in the Content-Dispositi
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **12.5.1** | [MOVED TO 14.3.6] | | | | |
-| **12.5.2** | [MOVED TO 50.5.1] | | | | |
+| **12.5.2** | [MOVED TO 50.6.1] | | | | |
 | **12.5.3** | [MODIFIED, MOVED FROM 12.3.4] Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | ✓ | ✓ | ✓ | 641 |
 | **12.5.4** | [ADDED] Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | ✓ | ✓ | ✓ | |
 

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 13.6.2] | | | | |
 | **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.3.1] | | | | |
+| **13.2.3** | [DELETED, MERGED TO 50.4.1] | | | | |
 | **13.2.4** | [DELETED, DUPLICATE OF 11.1.4] | | | | |
 | **13.2.5** | Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. | | ✓ | ✓ | 436 |
 | **13.2.6** | [MOVED TO 13.1.6] | | | | |

5.0/en/0x22-V14-Config.md

@@ -18,7 +18,7 @@ Configuration of the application out of the box should be safe to be on the Inte
 | **1.14.3** | [DELETED, DUPLICATE OF 14.2.1] | | | | |
 | **1.14.4** | [DELETED, NOT IN SCOPE] | | | | |
 | **1.14.5** | [SPLIT TO 1.10.4, 10.5.1] | | | | |
-| **1.14.6** | [MOVED TO 50.7.2] | | | | |
+| **1.14.6** | [MOVED TO 50.8.2] | | | | |
 | **1.14.7** | [MODIFIED, MOVED FROM 1.1.5] Verify that all communication needs for the application are documented. This should include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | | ✓ | ✓ | 1059 |
 
 ## V14.1 Build and Deploy
@@ -50,7 +50,7 @@ Compliance with this section requires an automated build system, and access to b
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **14.2.1** | [MOVED TO 10.6.1] | | | | |
 | **14.2.2** | [MOVED TO 14.1.6] | | | | |
-| **14.2.3** | [MOVED TO 50.6.1] | | | | |
+| **14.2.3** | [MOVED TO 50.7.1] | | | | |
 | **14.2.4** | [DELETED, MERGED TO 1.10.2] | | | | |
 | **14.2.5** | [MOVED TO 1.10.2] | | | | |
 | **14.2.6** | [SPLIT TO 1.10.3, 10.5.1] | | | | |
@@ -75,20 +75,20 @@ For example, hiding the version of server-side components does not fix the need
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **14.4.1** | [MOVED TO 13.1.7] | | | | |
-| **14.4.2** | [DELETED, MERGED TO 50.5.1] | | | | |
-| **14.4.3** | [MOVED TO 50.2.1] | | | | |
-| **14.4.4** | [MOVED TO 50.2.2] | | | | |
-| **14.4.5** | [MOVED TO 50.2.3] | | | | |
-| **14.4.6** | [MOVED TO 50.2.4] | | | | |
-| **14.4.7** | [MOVED TO 50.2.5] | | | | |
+| **14.4.2** | [DELETED, MERGED TO 50.6.1] | | | | |
+| **14.4.3** | [MOVED TO 50.3.1] | | | | |
+| **14.4.4** | [MOVED TO 50.3.2] | | | | |
+| **14.4.5** | [MOVED TO 50.3.3] | | | | |
+| **14.4.6** | [MOVED TO 50.3.4] | | | | |
+| **14.4.7** | [MOVED TO 50.3.5] | | | | |
 
 ## V14.5 HTTP Request Header Validation
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **14.5.1** | [MOVED TO 13.6.1] | | | | |
 | **14.5.2** | [DELETED, DUPLICATE OF 4.1.1] | | | | |
-| **14.5.3** | [SPLIT TO 50.2.6, 50.3.3] | | | | |
+| **14.5.3** | [SPLIT TO 50.3.6, 50.4.3] | | | | |
 | **14.5.4** | [DELETED, INCORRECT] | | | | |
 
 ## V14.6 Web or Application Server Configuration

5.0/en/0x52-V52-Tokens.md

@@ -12,7 +12,7 @@ Before inspecting the contents of a self-contained token, it is necessary to ens
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **52.1.1** | [MOVED FROM 3.5.3, MODIFIED, LEVEL L2 > L1] Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
+| **52.1.1** | [MODIFIED, MOVED FROM 3.5.3, LEVEL L2 > L1] Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
 | **52.1.2** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 |
 | **52.1.3** | [ADDED] Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | ✓ | ✓ | ✓ | |