Findings
Missing 429 response
Updated: June 19, 2025
Description
An endpoint is missing a rate limit response.
When designing or consuming an API, one of the primary concerns is the predictability and reliability of communication between the client and server. At the heart of this predictability lies the many different HTTP status codes, which inform the client about the outcome of its requests. The 429 Too Many Requests response is among these status codes. This response is indicative of rate limiting, which is a common strategy used by API providers to prevent abuse and overuse of resources. This mechanism ensures fair usage, guards against unintentional programming errors that might flood an API, and protects backend services from becoming overwhelmed, thereby preventing degradation in service quality. Including a definition for the 429 response in API specifications will explicitly communicate to consumers of an API the possibility that they might be rate-limited. This not only sets clear expectations but also prompts developers to handle such scenarios gracefully in their applications. If an API client is unaware of the potential for a 429 response, error handling may not be graceful, leading to unpredictable behavior and potential failures in real-world scenarios.
This rule applies at the API Specification level (OAS/Swagger).
Example Attack
Brute Force Attacks: Without rate limiting enforced by a 429 response, attackers can conduct brute force attacks more efficiently. For example, they can repeatedly attempt to log in with different credentials or submit requests to vulnerable endpoints at a rapid pace, increasing the likelihood of successfully guessing passwords or exploiting vulnerabilities.
Remediation
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.Ensure API specifications include definitions for 429 responses.
Security Frameworks
Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs.
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
CIS-ASG-2.2.4: CIS 2.2.4: Enforce Rate Limiting mechanisms
Enforce rate limiting mechanisms to provide protection from repeated requests that target an endpoint.
Rationale
Enforcing rate limiting mechanisms helps prevent Distributed Denial of Service (DDoS) and brute-force attacks by limiting the number of requests an attacker can make within a given timeframe. This ensures the availability of services for legitimate users and protects server resources from being overwhelmed. Compliance requirements often mandate implementing such measures to enhance security. By maintaining Quality of Service (QoS), rate limiting ensures a consistent and reliable experience for users while mitigating the risk of abuse or exploitation of system resources.
Remediation
- Update rate-limiting configurations.
- Implement behavioral rate-limiting based on session and/or IP behavior.
- Enforce logging and monitoring procedures.
- Deploy distributed rate limiting (load balancers), CDNs, WAFs, IDS/IPS).
- Document all actions taken.
Audit
- Review the application architecture.
- Analyze existing rate-limiting configurations.
- Examine the logs.
- Review regulation compliance and check if it is currently inline with regulations.
- Evaluate Denial of Service (DoS) resilience.
- Perform stress tests on existing rate limiting mechanisms.
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.