Findings
Missing rate limit headers
Updated: June 19, 2025
Description
Endpoints should use proper rate limiting to ensure service availability to all users.
Developers incorporate headers such as 'X-RateLimit-Limit', 'X-Rate-Limit-Limit', 'RateLimit-Limit', and 'RateLimit-Reset' in HTTP responses to manage and communicate the rate limits of their API or web service to the client. By including these headers, developers give API consumers insight into how many requests they can make in a specified period, preventing unintentional breaches of the rate limit. They also allow API clients to implement adaptive strategies. With information about their remaining requests and when the rate limit will reset, clients can adjust their request patterns, spreading out their calls, or pausing until the rate limit resets, thereby avoiding any disruption to their operations. Additionally, rate limiting protects an API from being overwhelmed by too many requests, which could degrade the service quality for all users. By clearly communicating these limits, developers ensure a balanced distribution of resources among all consumers.
This rule applies at the API Specification level (OAS/Swagger).
Example Attack
Resource Exhaustion: In the absence of rate limit headers, attackers can abuse endpoints that consume significant resources, such as generating complex reports or processing large datasets. Attackers can disrupt the availability of a service, degrade system performance, and exhaust server resources by continuously sending requests without limitations.
Remediation
Include 'X-RateLimit-Limit', 'X-Rate-Limit-Limit', 'RateLimit-Limit' or 'RateLimit-Reset' in the HTTP headers to avoid unintended service disruption.
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.