Lack of Resources & Rate Limiting is an API security weakness in which an API fails to impose appropriate limits on the number, frequency, or size of requests a client can make, and on the resources those requests can consume. It featured in the OWASP API Security Top 10 (as API4:2019). Without such limits, an API is vulnerable to being overwhelmed, abused, or exploited – because attackers can send excessive requests or demand excessive resources, degrading performance, driving up costs, or enabling other attacks.
APIs consume resources to satisfy requests – CPU, memory, storage, network bandwidth – and some operations also incur external costs, such as sending emails or SMS messages, or invoking paid third-party services. When an API does not restrict how many requests a client may make in a given time, how large requests or responses may be, or how much work a single request can trigger, several problems arise. Attackers can launch denial-of-service attacks by flooding the API with requests or by crafting expensive requests that exhaust resources. They can brute-force credentials or enumerate data without restriction, since nothing throttles their high-volume automated attempts. They can drive up operational costs by triggering resource-intensive or billable operations at scale. And they can exploit endpoints that return large or unbounded amounts of data.
Rate limiting is the primary control that addresses this weakness. It restricts how many requests a given client (identified by API key, token, IP, user, or other attributes) may make within a time window, rejecting or throttling requests beyond the limit. Related controls include limiting request and response payload sizes, capping the number of records returned (pagination), constraining resource-intensive operations, limiting query complexity (especially important for GraphQL), and setting quotas. Together these protect availability, control costs, and blunt automated attacks like credential stuffing and scraping by removing the ability to operate at unlimited scale.
The absence of these controls is particularly damaging for APIs because APIs are built for programmatic, automated access, so an unprotected endpoint invites automated abuse. Rate limiting and resource controls are therefore foundational to API security – not only for defending against denial-of-service, but as a brake on the automated, high-volume behavior underlying many API attacks. Effective implementation applies sensible limits tuned to legitimate usage, distinguishes between clients appropriately, and combines rate limiting with monitoring so that clients hitting limits or exhibiting abusive patterns can be detected and investigated.