Get a Demo

Welcome back to the OWASP API Security Top 10 series, this week we go through number 4 in the OWASP API top 10 list: Lack of Resources & Rate Limiting. For other blogs in this series, please refer to the below link:

Click here.

Lack of Resources and Rate Limiting, as the name suggests, is a common problem for Web applications as well as APIs. While denial of service and rate limiting is discussed as part of other sections in the OWASP Web Top 10 but not as a separate category, it is included in the API Top 10 because of how frequently this attack is observed in the wild. This kind of attack is launched through APIs in an attempt to force the application to fall over by overwhelming network, CPU, memory, and/or storage resources. This form of exploit often results in a sluggish behavior, system crashes, or other rogue server behaviors, resulting in denial-of-service. It is also to be noted that many load-based denial-of-service incidents in large systems are unintentional, caused by errors in software or configurations in some other part of the system, not malicious attacks (such as network-based distributed denial of service attacks).

Now let us look at couple of example attack scenarios:

Zoom Meetings Password Cracking Due to Lack of Rate Limiting

Zoom is the popular video/web conferencing choice to conduct online meetings for many organizations and even private users commonly use Zoom. Tom Anthony from SearchPilot discovered an issue where the Zoom web client allowed brute force attempts to crack password protected private meetings that occurred in Zoom. Before the fix was issued, Zoom generated passwords were of 6 digits in length. This means that there are only 6 million odd combinations to try and by writing a simple script which sends a couple of requests per candidate password: one to submit the password and other to validate if the previous request was a success, Tom was able to successfully crack the password and join private meetings.

Let us look at another example which is a theoretical attack and causes a denial of service to an API. Most APIs provide access to resources that are lists of entities, so let us assume the following API is responsible for retrieval of users and information related to them. A client such as a browser would typically filter and paginate through this list to limit the number items returned to a client.

In this case, the request would return with the first page and the first 100 users. If the size parameter was not validated properly and say an attacker modified the size parameter to a large value such as 1000000, it could cause a performance issue on the backend database, since the size parameter in use is so large. As a result, the API becomes unresponsive and is unable to handle further requests from this or any other client.

Few other real world issues published which fall under API4 – Lack of Resources & Rate Limiting category are:

Protection Mechanisms

DoS and DDoS require multiple levels of protection. Limiting resources is one way. While developing the product, attention has to be given to resources such as memory, CPU, maximum number of restarts (–restart=on-failure:), maximum number of file descriptors (–ulimit nofile=) and maximum number of processes (–ulimit nproc=). Same is applicable to docker applications as well: Assign Memory Resources to Containers and Pods, Assign CPU Resources to Containers and Pods and Assign Extended Resources to a Container.

Rate limiting or throttling as a mechanism to protect resources is good but not sufficient. Instead, focus on identifying the APIs which are more likely to be attacked such as the ones related to authentication, signup, password reset, and sensitive information access and setup policies that would limit mass use and include automated lockouts to prevent abuse.

Evolution of microservices and API usage opened up multiple ways in which API can be accessed and the ability to programmatically launch APIs makes DDoS protection tricky. Most DDoS protection solutions rely on HTTP fingerprinting to find bad actors and reject the requests while allowing the legitimate ones. But with API traffic, it is really difficult to distinguish bot traffic from normal traffic. It is necessary to rely on software that supports advanced API monitoring with the help of machine learning models that effectively categorize APIs that are more likely to be attacked and at the same time detect bot traffic with accuracy.

If you would like to understand how CloudVector can help protect against OWASP API Top 10, please feel free to reach out at

Sekhar Chintaginjala

Sekhar Chintaginjala is an experienced information security researcher who brings 15+ years of hands-on knowledge to the CloudVector team. He has proven expertise in the area of vulnerability research, security content development and leading teams for large global companies. At CloudVector, Sekhar is a member of the Security Research team and also leads efforts for new feature development that help protect from API abuses.