Findings
Missing 500 response
Updated: June 19, 2025
Description
An endpoint is missing the definition for a 500 response.
500 responses indicate a server-side errors. By providing a definition, APIs can offer meaningful information about what went wrong. When API consumers encounter a 500 response, having a clear definition helps them understand the nature of the problem and whether it's something that would need addressing on the client side, or if it is an issue with the server. Including definitions for 500 responses in the API specifications promotes transparency and professionalism. It shows that the developers have considered various scenarios and are prepared to handle unexpected situations.
This rule applies at the API Specification level (OAS/Swagger).
Example Attack
Information Disclosure: In the absence of a 500 response, the server might disclose sensitive information such as configuration details or software versions through error messages. Attackers could use this information to identify any potential vulnerabilities or exploit misconfigurations.
Remediation
Ensure API specifications include definitions for 500 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.