When an API consumer sends an invalid request, a 400 Bad Request response indicates that the server couldn't understand the request due to invalid syntax. A 422 Unprocessable Entity response signifies that the server understands the request, but it can't process it due to semantic errors. By specifying these responses, developers offer guidance to API consumers on the nature of their mistakes, allowing them to diagnose and rectify issues more efficiently. By defining a range of 4XX responses, developers can cater to various error scenarios, ensuring that the API provides meaningful feedback for a wide array of potential client-side issues. This not only enhances the user experience but also reduces the support burden on the API provider, as consumers are better equipped to troubleshoot problems on their own.
This rule applies at the API Specification level (OAS/Swagger).
Input Validation Bypass: Without receiving a proper 400 response for invalid input, attackers can potentially submit malformed or unexpected data to the API endpoint. This could lead to the API processing the input incorrectly, possibly resulting in unexpected behavior or security vulnerabilities.