merge anti-automation requirements (closes #971)

4.0/en/0x19-V11-BusLogic.md

@@ -17,7 +17,7 @@ Business logic security is so individual to every application that no one checkl
 | **11.1.1** | Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.| ✓ | ✓ | ✓ | 841 |
 | **11.1.2** | Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.| ✓ | ✓ | ✓ | 799 |
 | **11.1.3** | Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis. | ✓ | ✓ | ✓ | 770 |
-| **11.1.4** | Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks. | ✓ | ✓ | ✓ | 770 |
+| **11.1.4** | [MODIFED, MERGED 13.2.4] Verify that application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks. | ✓ | ✓ | ✓ | 770 |
 | **11.1.5** | Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies. | ✓ | ✓ | ✓ | 841 |
 | **11.1.6** | Verify the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations. | | ✓ | ✓ | 367 |
 | **11.1.7** | Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)) | | ✓ | ✓ | 754 |

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

@@ -35,7 +35,7 @@ Once the JSON schema validation standard is formalized, ASVS will update its adv
 | **13.2.1** | Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. | ✓ | ✓ | ✓ | 650 |
 | **13.2.2** | Verify that JSON schema validation is in place and verified before accepting input. | ✓ | ✓ | ✓ | 20 |
 | **13.2.3** | [DELETED, MERGED TO 4.2.2] | | | | |
-| **13.2.4** | Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated. | | ✓ | ✓ | 770 |
+| **13.2.4** | [DELETED, MERGED TO 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** | Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits. | | ✓ | ✓ | 345 |