Lack of Resource & Rate Limiting: OWASP API-04

Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer

Get a Demo

API-04 Lack of Resource & Rate Limiting

Harold Bell

Lack of resource and rate limiting occurs when an API fails to sufficiently protect itself from overuse or abuse which negatively impacts availability. This issue is usually thought to be caused by malicious actors purposefully trying to consume all the resources of an API. However, less nefarious instances of this can also occur. Consider an API used by multiple businesses in a business to business situation. One of the businesses using the API may make an excessive, though not malicious, number of requests and cause other businesses to receive slow or no responses to their API calls. In either the malicious or mistaken case, properly configured resource and rate limiting can keep an API available to its clients.

How does this happen?

For APIs even at a small scale, there are many different stakeholders and teams involved in properly deploying a secure API. Configuration mistakes are generally the cause of missing rate or resource limiting. Configuration issues may occur at the load balancer (blunt rate limiting), at the API gateway (if present), inline networking gear, at the CDN or at the API itself depending on the deployment environment. A lack of performance or load testing can also lead to missing limits or limits set too low to adequately protect an API.

Continuing the online retailer example, an attacker notices that the profile page for customers includes an optional avatar to personalize the customer experience. The profile page also includes the functionality to upload an image for your avatar. The attacker makes an API call including an excessively large image file which consumes all the resources of the API as it attempts to resize the image to the proper dimensions. As resources are consumed by this attack, the API responses get increasingly slow until the API becomes unavailable. With a simple large file upload, the attacker has taken the API offline. This is an application-level denial of service (DOS) attack.

Why is it important?

An API is created to allow for the exchange of data between programs in an automated and performant fashion. By failing to establish resource and rate limiting controls, APIs are at risk of violating one of the 3 central principles of information security: Availability. Along with Confidentiality and Integrity, cybersecurity professionals call this the CIA triad. Considering the fact that the API was created to exchange data for a business reason, downtime or degraded performance of an API represents a risk to the business. If the API is directly related to revenue generating activities, downtime can mean loss of revenue, violations of contractual obligations and potential legal action.

There are several places where resource and rate limits should be considered. First, at the networking layer, request size should be limited to maximum size. For our online retailer example, a simple network control on the maximum size of any HTTPS request could prevent the DOS attack. Another place to consider rate limits is the number of concurrent requests from any single client. Such protections can prevent a single client from ‘hogging’ the API at the expense of other clients. These limits may be imposed at a load balancer, an API gateway, a WAF, a reverse proxy or other infrastructure which handles the APIs requests. Also, the API itself needs to protect itself from attack by imposing limits on submission of data as well as providing data to clients. For example, an API which does not paginate data sent to the client may allow an attacker to create so many data items that getting a list of them will consume all the APIs available resources. Yet another way to cause a denial of service (DOS) attack.

It is important to note that while denial of service attacks are generally conducted by malicious actors, a poorly programmed client may innocently create enough traffic to degrade performance or availability of an API. So, even APIs that are between trusted partners are not safe from these risks.

Example

Continuing with the online retailer example, below is a valid request from Alice adding a reasonably sized image (4.6 MB) as her avatar:

POST /api/v2/customer/avatar HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: multipart/form-data; boundary=---------------------------10934607322183697996431206174

Content-Length: 4600000

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.m0ha0L89xuLpLlLlyb

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin

---------------------------10934607322183697996431206174

Content-Disposition: form-data; name='avatar-upload'; filename='alice.png'

Content-Type: image/png

[base64 encoded data removed for brevity]

After the API accepts and resizes the image, Alice will have a custom avatar while logged into the online retailers site.

However, Mallory uses a specially crafted, excessively large image file (4.6 GB) to send to the API:

POST /api/v2/customer/avatar HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: multipart/form-data; boundary=---------------------------10934607322183697996431206174

Content-Length: 4939212000

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.m0ha0L89xuLpLlLlyb

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin

---------------------------10934607322183697996431206174

Content-Disposition: form-data; name='avatar-upload'; filename='malory.png'

Content-Type: image/png

[base64 encoded data removed for brevity]

By sending such a large file, Mallory has successfully consumed all the API resources and caused a Denial of Service attack.

How to test

Attackers and penetration testers discover insufficient resource and rate limits looking for requests which allow adding or listing large amounts of data. As mentioned above, this could be API responses which lack pagination or file uploads. Additionally, many attackers will utilize fuzzing tools while assessing/attacking an API. While fuzzing, responses which take longer than usual are an indicator of a potential DOS attack.

What is fuzzing?

In the context of API testing, fuzzing involves sending unexpected data to an API in an attempt to find flaws in the software powering the API. The data sent could be very large, very small or negative numbers, unexpected characters (Unicode), or anything unexpected such as sending ‘<script>alert(‘vulnerable’)</script>’ into a field expecting a telephone number.

Many automated dynamic API scanners (DAST tools) will conduct a mild version of fuzzing as the test for potential injection vulnerabilities and may discover a lack of resource or rate limits. Quality testing, especially performance testing, is likely to find areas which need limiting as well as provide information on where to set limits to adequately protect an API. Specialized HTTP/API fuzzing tools also exist to find APIs which are susceptible to DOS attack or particularly resource intensive.

How Noname protects

Noname’s API security platform can help protect APIs lacking resource or rate limiting in multiple ways. Noname provides a ‘shift left’ approach to security testing so software vulnerabilities which can lead to resource consumption attacks can be found before APIs are deployed to production. The platform provides granular testing capabilities with templated configurations for many popular CICD platforms. Early testing in pre-production environments can reduce or eliminate resource or rate limiting issues before attackers have a chance to find them.

Noname also provides runtime protection that includes deep inspection and machine learning to analyze all traffic going to or from APIs. It understands multiple API types such as REST, GraphQL, SOAP, gRPC. By understanding API communication methods, deeply inspecting traffic and utilizing ML, Noname’s platform can notice that API requests have been modified to evade limits or are happening at excessive rates. It also includes anomaly detection and can alert on a surge of requests for a specific API endpoint typical of denial of service attack. When an attack is discovered, Noname allows for a flexible range of responses to the alerts raised. At the most basic, it will provide alerts in the Noname web UI. More interesting are the integrations with ticketing systems available which allow Noname alerts to be triaged by the security team. Additionally, Noname can provide fully automated responses by interacting with existing infrastructure to take actions like blocking an IP for a period of time or de-authenticating a client’s token at the API gateway.

Finally, Noname’s platform provides API posture management capabilities. Leveraging Noname’s runtime monitoring, the platform will dynamically create an inventory of all APIS including those that include sensitive data in their responses. Noname inventories APIs based on the hostname, path/URI and HTTP method allowing for granular controls to be established across the entire API inventory. Beyond creating an inventory, data received and sent are auto-classified. The platform also allows for custom data types to be created to accommodate business-specific data. Using the auto-classified data, policies can be created to restrict sensitive data in API communications. Any policies on data are enforced by the platform’s runtime protection including any of the responses mentioned above – manual, semi-automatic or full automatic responses. By having a complete API and data inventory, resource and rate limiting activities can concentrate on the APIs which provide the most value to the business to reduce the risks arising from insufficient resource and rate limiting.