Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
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.
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.
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.
If we try to trigger this call multiple times we will notice rate limiting on the endpoint.
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
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.
20+ years IT expertise in system engineering, security analysis, solutions architecture. Proficient in OS (Windows, Linux, Unix), programming (C++, Python, HTML/CSS/JS, Bash), DB (MySQL, Oracle, MongoDB, PostgreSQL). Skilled in scripting (PowerShell, Python), DevOps (microservices, containers, CI/CD), web development (Node.js, React, Angular). Successful track record in managing IT systems.
Stepan is a cybersecurity expert proficient in Python, Java, and C++. With a deep understanding of security frameworks, technologies, and product management, they ensure robust information security programs. Their expertise extends to CI/CD, API, and application security, leveraging Machine Learning and Data Science for innovative solutions. Strategic acumen in sales and business development, coupled with compliance knowledge, shapes Wallarm's success in the dynamic cybersecurity landscape.