Join us at 2024 API And Application Security Summit in Columbus!
Join us at 2024 API And Application Security Summit in Columbus!
Join us at 2024 API And Application Security Summit in Columbus!
Join us at 2024 API And Application Security Summit in Columbus!
Join us at 2024 API And Application Security Summit in Columbus!
Join us at 2024 API And Application Security Summit in Columbus!
Privacy settings
We use cookies and similar technologies that are necessary to run the website. Additional cookies are only used with your consent. You can consent to our use of cookies by clicking on Agree. For more information on which data is collected and how it is shared with our partners please read our privacy and cookie policy: Cookie policy, Privacy policy
We use cookies to access, analyse and store information such as the characteristics of your device as well as certain personal data (IP addresses, navigation usage, geolocation data or unique identifiers). The processing of your data serves various purposes: Analytics cookies allow us to analyse our performance to offer you a better online experience and evaluate the efficiency of our campaigns. Personalisation cookies give you access to a customised experience of our website with usage-based offers and support. Finally, Advertising cookies are placed by third-party companies processing your data to create audiences lists to deliver targeted ads on social media and the internet. You may freely give, refuse or withdraw your consent at any time using the link provided at the bottom of each page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
API Security, OWASP, Attacks

Lack of Resources and Rate Limiting


API4:Lack of Resources Rate Limiting

Threat agents/Attack vectorsSecurity WeaknessImpacts
This vulnerability type is made possible because endpoints that serve data can be called upon many times per second by users/attackers. If the user/attack requests so data so many times the system can no longer keep up and starts consuming all of its resources this can even lead to a DoS (Denial Of Service) attack but the consequences might be even greater than that on certain authentication endpoints which might open the API up to forgotten password reset token brute forcing.This security vulnerability is common in the wild and thus we may often encounter API's that contain no or weak rate limiting. Weak rate limiting can be defined in several ways but as long as the rate limiting is not sufficient for the purpose it server (like for example resource protection or protection against password attacks) it is not sufficient.The impact can range from something like DoS up to enable authentication attacks, these are all in the higher end of the impact range because they have some serious potential to disrupt the normal workings of our API.
Lack of Resources and Rate Limiting

What is Lack of Resources and Rate Limiting?

Whenever an API is served a request it will have to respond, to generate this response the API requires resources (CPU, RAM, network and at times even disk space) but how much are required highly depends on the task at hand. The more logic processing happens or data is returned, the more resources are taken up by a single call and this can stack on quick. If we do not rate limit our API endpoints. This issue is made even worse by the fact that most API's reside on shared hosts which means they are all fighting for the same resources which could mean the attacker is disabling a secondary unrelated API by consuming all the resources. Avoiding these problems will help API Security Company.

Lack of Resources Rate Limiting example

Example Attack Scenarios

There are simple examples of attacks related to lack of rate limiting on endpoint but those are easy enough, a somewhat deeper attack could be a user who discovers the endpoint to create a file which does have rate limiting and an endpoint to copy a file does not have rate limiting. At first this might seem hard to abuse but if we create a document on the system that has a large file size and then copy it over, we might trigger the server to run out of resources.


POST /createDocument.php
        "Name": "677",
        "Content": "AAAAA...AAAA",

With a response of the ID:


If we try to trigger this call multiple times we will notice rate limiting on the endpoint.

GET /cloneDocument.php?id=12

But there might be a GET call which is not rate limited and by triggering it multiple times we might consume all of the server's resources.

Let's add another example to make things more clear. We might be trying to recall the last 100 posts to a blog with the following URL

GET /api/v1/posts?limit=100

By executing this request with a parameter of limit=99999 we might trigger a lack of resources as well and this is also counted as lack of endpoint rate limiting.

Preventive measures against lack of rate limiting

  • Using a docker container can be very handy as it has built-in flags such as -m to determine exactly how much memory every container may consume. This also allows for a much easier separation of different APIs.
  • We should make sure the client can only make a certain amount of request over a certain period. If we do this however we have to make sure that the client is notified when a rate limit is triggered or about to be triggered. This message should contain the amount of remaining requests before the limit is hit and/or the remaining time of the rate limit
  • We need to verify on the client and server side that the request body and response are not too big. This is especially true for endpoints that return an amount of records specified by the client. The client can manipulate the amount of requests and cause a severe issue to occur if they request too many records at a time.
  • Every data type that the endpoint accepts should have an upper limit, for example integers should be limited to 5999. This ensures we never expose too great of a volume of data.


This again deceptive vulnerability is hard to overlook but can be a bit easier to automate as all we have to do is check all the API endpoints and see if they enforce a maximum size to the input or output, this requires a good understanding of what the APIs should accept or return. Better yet, good documentation helps identify issues easier which costs less in the long run. Read our article Comparing OWASP Top-10 2021 and 2017 Vulnerabilities.

Watch the video:



Subscribe for the latest news

March 5, 2024
Learning Objectives
Subscribe for
the latest news
Related Topics