Get the latest Gartner® insights on API Protection

Learn more

API4:2019 Lack of Resources & Rate Limiting

Michael IsbitskiMichael Isbitski
Feb 10, 2021


API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the input from the user and the business logic of the endpoint. APIs do not always impose restrictions on the size or number of resources that can be requested by the client or user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but it also leaves the door open to brute-forcing and enumeration attacks against APIs that provide authentication and data fetching functionality. This includes automated threats like credential cracking and token cracking among others.

Get the comprehensive list of best practices to guide your API security journey.

Potential Impact

When determining impact, it is best to break down the impact of this issue into two sub-components:

  1. With respect to lack of resource limiting, an attacker can craft a single API call that can overwhelm an application, impacting the application’s performance and responsiveness or causing it to become unresponsive. This type of attack is sometimes referred to as an application-level DoS. These types of attacks not only impact availability though. They may also expose the system, application or API to authentication attacks and excessive data leakage. 
  2. With respect to lack of rate limiting, an attacker may craft and submit high volumes of API requests to overwhelm system resources, brute force login credentials, quickly enumerate through large data sets, or exfiltrate large amounts of data.


In the example above of a lack of resource limit, the attacker has increased the max_return and page_size values for the search filter from 250 to 20,000. This increase would cause the application to return an excessive number of items in response to a query. It could also cause the application to slow down or become unresponsive for all users.

Real World Example

Checkmarx Research: SoundCloud API Security Advisory

In 2020 the Checkmarx research team found that SoundCloud had not properly implemented rate limiting for the /tracks endpoint of the API. Since no validation was performed for the number of track IDs in the ids list, an attacker could manipulate the list to retrieve an arbitrary number of tracks in a single request and overwhelm the server. Under normal conditions the request issued by the SoundCloud WebApp includes 16 track IDs in the ids query string parameter. The researcher was able to manipulate the list to retrieve up to 689 tracks in a single request causing the service response time to increase by almost 9x. According to Checkmarx “This vulnerability could be used to execute a Distributed Denial of Service (DDoS) attack by using a specially crafted list of track IDs to maximize the response size, and issuing requests from several sources at the same time to deplete resources in the application layer will make the target’s system services unavailable.”

Why Existing Tools Fail to Protect You

Traditional security controls like WAFs, API gateways, and other proxying mechanisms will commonly offer basic or static rate limiting which are difficult to enforce at scale. Security teams may not know enough about the application design to know what “normal” looks like in order to enforce limits to thwart attackers while not impacting business functionality. WAFs and API gateways lack the context required to inform security teams on what a normal value should be for an API parameter, and they will miss attacks where an attacker manipulates a single API parameter value to overwhelm the application. These proxies may also only cover ingress, or inbound requests, as opposed to egress traffic, or outbound requests and responses.

How to Protect Against Lack of Resources & Rate Limiting Attacks

An API security solution must be able to identify calls to API endpoints and alterations to API parameter values that fall outside of normal usage. This would be done by analyzing all API traffic in order to create a baseline of typical behavior and identifying deviations that fall outside of that baseline. 

In the example above an API security solution will have created a baseline of values for the max_return and page_size parameters and will identify that a value of 20,000 is abnormal. The solution could then alert on and block an attacker who crafts API requests that deviate from the baseline.

Previous posts:

OWASP API Security Top 10 Explained

API1:2019 Broken Object Level Authorization

API2:2019 Broken User Authentication

API3:2019 Excessive Data Exposure

Next post:

API5:2019 Broken Function Level Authorization

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection

API9:2019 Improper Assets Management

API10:2019 Insufficient Logging & Monitoring

Go back to blog

Download this guide for advice on evaluating key capabilities in API Security

Get the guide