Findings
Missing 4xx response
Updated: June 19, 2025
Description
An endpoint is missing the definition for a 4xx response.
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).
Example Attack
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.
Remediation
Ensure API specifications include definitions for 400, 422, and 4XX responses. API endpoints that do not return HTTP status code descriptions are more difficult to use for developers. Adding standard responses to API specifications ensures use of those APIs is predictable and safe.
Security Frameworks
This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
CIS-ASG-2.3.2: CIS 2.3.2: Establish standardized error handling procedures
Put in place a consistent procedure to handle errors.
Rationale
Establishing standardized error handling procedures ensures consistency across the API, providing a uniform approach to managing and communicating errors. This improves the clarity and usefulness of error messages for developers and users, enhancing overall user experience. It also prevents revealing sensitive information that could help attackers.
Remediation
- Improve the clarity of error messages.
- Establish guidelines for handling errors.
- Enforce HTTP return status compliance.
- Update the documentation accordingly.
Audit
- Review the documentation by inspecting the existing error format that is in place.
- Identify potential disclosure of internal system information in error messages.
- Assess all existing error message quality - is it comprehensive, does it correctly communicate the error.
- Verify HTTP standards compliance, for example 404 error should be used for non-existing resources, 401/403 error codes should be used for unauthorized access and so on.