Coders Conquer Security OWASP Top 10 API Series - Lack of Resources and Rate Limiting
Coders Conquer Security OWASP Top 10 API Series - Lack of Resources and Rate Limiting
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b68b30ab426193ae7876_601109cb6f32a39624f121ad_CCC-1.webp)
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b68b30ab426193ae7876_601109cb6f32a39624f121ad_CCC-1.webp)
With the lack of resources and rate limiting, API vulnerability acts almost exactly how it's described by the title. Every API has limited resources and computing power available to it depending on its environment. Most are also required to field requests from users or other programs asking it to perform its desired function. This vulnerability occurs when too many requests come in at the same time, and the API does not have enough computing resources to handle those requests. The API can then become unavailable or unresponsive to new requests.
APIs become vulnerable to this problem if their rate or resource limits are not set correctly, or if limits are left undefined in the code. An API can then be overloaded if, for example, a business experiences a particularly busy period. But it's also a security vulnerability, because threat actors can purposely overload unprotected APIs with requests in order to perform Denial of Service (DDoS) attacks.
By the way, how are you doing with the API gamified challenges so far? If you want to try your skills in handling a rate limiting vulnerability right now, step into the arena:
Now, let's go a little deeper.
What are some examples of the lack of resources and rate limiting API vulnerability?
There are two ways that this vulnerability can sneak into an API. The first is when a coder simply doesn't define what the throttle rates should be for an API. There might be a default setting for throttle rates somewhere in the infrastructure, but relying on that is not a good policy. Instead, each API should have its rates set individually. This is especially true because APIs can have vastly different functions as well as available resources.
For example, an internal API designed to serve just a few users could have a very low throttle rate and work just fine. But a public-facing API that is part of a live eCommerce site would most likely need an exceptionally high rate defined to compensate for the possibility of a surge in simultaneous users. In both cases, the throttling rates should be defined based on the expected needs, the number of potential users, and the available computing power.
It might be tempting, especially with APIs that will most likely be very busy, to set the rates to unlimited in order to try and maximize performance. This could be accomplished with a simple bit of code (as an example, we'll use the Python Django REST framework):
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
In that example, both anonymous users and those known to the system can contact the API an unlimited number of times without regard to the number of requests over time. This is a bad idea because no matter how much computing resources an API has available, attackers can deploy things like botnets to eventually slow it to a crawl or possibly knock it offline altogether. When that happens, valid users will be denied access and the attack will be successful.
Eliminating Lack of Resources and Rate Limiting Problems
Every API that is deployed by an organization should have its throttle rates defined in its code. This could include things like execution timeouts, maximum allowable memory, the number of records per page that can be returned to a user, or the number of processes permitted within a defined timeframe.
From the above example, instead of leaving the throttling rates wide open, they could be tightly defined with different rates for anonymous and known users.
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
In the new example, the API would limit anonymous users to making 200 requests per hour. Known users who are already vetted by the system are given more leeway at 5,000 requests per hour. But even they are limited to prevent an accidental overload at peak times or to compensate if a user account is compromised and used for a denial of service attack.
As a final good practice to consider, it's a good idea to display a notification to users when they have reached the throttling limits along with an explanation as to when those limits will be reset. That way, valid users will know why an application is rejecting their requests. This can also be helpful if valid users doing approved tasks are denied access to an API because it can signal operations personnel that the throttling needs to be increased.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Resources to get you started
Trust Agent by Secure Code Warrior
Discover SCW Trust Agent, an innovative solution designed to enhance security by aligning developer secure code knowledge and skills with the work they commit. It provides comprehensive visibility and controls across an organization's entire code repository, analyzing each commit against developers' secure code profiles. With SCW Trust Agent, organizations can strengthen their security posture, optimize development lifecycles, and scale developer-driven security.
Resources to get you started
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
SCW Trust Agent - Visibility and Control to Scale Developer Driven Security
SCW Trust Agent, introduced by Secure Code Warrior, offers security leaders the visibility and control needed to scale developer-driven security within organizations. By connecting to code repositories, it assesses code commit metadata, inspects developers, programming languages used, and shipment timestamps to determine developers' security knowledge.
Coders Conquer Security OWASP Top 10 API Series - Lack of Resources and Rate Limiting
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b68b30ab426193ae7876_601109cb6f32a39624f121ad_CCC-1.webp)
With the lack of resources and rate limiting, API vulnerability acts almost exactly how it's described by the title. Every API has limited resources and computing power available to it depending on its environment. Most are also required to field requests from users or other programs asking it to perform its desired function. This vulnerability occurs when too many requests come in at the same time, and the API does not have enough computing resources to handle those requests. The API can then become unavailable or unresponsive to new requests.
APIs become vulnerable to this problem if their rate or resource limits are not set correctly, or if limits are left undefined in the code. An API can then be overloaded if, for example, a business experiences a particularly busy period. But it's also a security vulnerability, because threat actors can purposely overload unprotected APIs with requests in order to perform Denial of Service (DDoS) attacks.
By the way, how are you doing with the API gamified challenges so far? If you want to try your skills in handling a rate limiting vulnerability right now, step into the arena:
Now, let's go a little deeper.
What are some examples of the lack of resources and rate limiting API vulnerability?
There are two ways that this vulnerability can sneak into an API. The first is when a coder simply doesn't define what the throttle rates should be for an API. There might be a default setting for throttle rates somewhere in the infrastructure, but relying on that is not a good policy. Instead, each API should have its rates set individually. This is especially true because APIs can have vastly different functions as well as available resources.
For example, an internal API designed to serve just a few users could have a very low throttle rate and work just fine. But a public-facing API that is part of a live eCommerce site would most likely need an exceptionally high rate defined to compensate for the possibility of a surge in simultaneous users. In both cases, the throttling rates should be defined based on the expected needs, the number of potential users, and the available computing power.
It might be tempting, especially with APIs that will most likely be very busy, to set the rates to unlimited in order to try and maximize performance. This could be accomplished with a simple bit of code (as an example, we'll use the Python Django REST framework):
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
In that example, both anonymous users and those known to the system can contact the API an unlimited number of times without regard to the number of requests over time. This is a bad idea because no matter how much computing resources an API has available, attackers can deploy things like botnets to eventually slow it to a crawl or possibly knock it offline altogether. When that happens, valid users will be denied access and the attack will be successful.
Eliminating Lack of Resources and Rate Limiting Problems
Every API that is deployed by an organization should have its throttle rates defined in its code. This could include things like execution timeouts, maximum allowable memory, the number of records per page that can be returned to a user, or the number of processes permitted within a defined timeframe.
From the above example, instead of leaving the throttling rates wide open, they could be tightly defined with different rates for anonymous and known users.
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
In the new example, the API would limit anonymous users to making 200 requests per hour. Known users who are already vetted by the system are given more leeway at 5,000 requests per hour. But even they are limited to prevent an accidental overload at peak times or to compensate if a user account is compromised and used for a denial of service attack.
As a final good practice to consider, it's a good idea to display a notification to users when they have reached the throttling limits along with an explanation as to when those limits will be reset. That way, valid users will know why an application is rejecting their requests. This can also be helpful if valid users doing approved tasks are denied access to an API because it can signal operations personnel that the throttling needs to be increased.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Resources to get you started
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
SCW Trust Agent - Visibility and Control to Scale Developer Driven Security
SCW Trust Agent, introduced by Secure Code Warrior, offers security leaders the visibility and control needed to scale developer-driven security within organizations. By connecting to code repositories, it assesses code commit metadata, inspects developers, programming languages used, and shipment timestamps to determine developers' security knowledge.
Trust Agent by Secure Code Warrior
Discover SCW Trust Agent, an innovative solution designed to enhance security by aligning developer secure code knowledge and skills with the work they commit. It provides comprehensive visibility and controls across an organization's entire code repository, analyzing each commit against developers' secure code profiles. With SCW Trust Agent, organizations can strengthen their security posture, optimize development lifecycles, and scale developer-driven security.