Lack of Resources & Rate Limiting

The mechanism underlying this API security issue is quite straightforward: without limits, an API allows a user or hacker to upload a file of several GB, or make hundreds of thousands of requests to the API in such a short amount of time that the hardware that hosts the API cannot cope and is overwhelmed. This causes the API response time to increase sharply, which severely impacts service by reducing the amount of traffic that the API can handle, up to preventing any requests from being fulfilled entirely.

How does this security issue work?

The exploitation mechanism for overloading an API with requests does not require authentication. It is also parallelizable and scalable so that either a single machine or several machines can be used concurrently to make requests to an API. Hardware on the API’s side can experience buffer overflows and exceptions but also run out of CPU, memory, network bandwidth, or disk space resources. It’s important to note that without rate-limiting for login functionalities, brute-forcing a password becomes possible. In this case, the lack of rate-limiting is a facilitator for another type of attack. As APIs with missing or improperly configured rate limits exist, denial-of-service attacks are particularly “easy” to carry out. Actors who are typically interested in carrying out this type of exploitation are competitors, activists, terrorists, and people who have no ulterior motive besides their amusement.

Can we force clients to slow down the pace of requests?

To address this potential API security threat, it is important to have properly configured limitations on the access that users have to the API. This includes implementing limits on how often a client can call the API in a given timeframe, as well as “[adding] proper server-side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response,” [OWASP Report], and defining and enforcing file uploads, text input field size, and length limits, to essentially set limits on the number of resources that a user can access and use via the API. The OWASP report also suggests that using containerization with tools such as Docker; can help prevent physical hardware overload, as the container can have limited resources (CPU, memory, bandwidth) which are much smaller than the physical hardware’s resources.

While this vulnerability seems simple on the surface, the ability to rack up thousands of dollars in AWS resources or to unwittingly facilitate brute-forcing of user accounts earns it the fourth spot on this Top 10 API security vulnerability list.