LAST UPDATED December 11, 2023
NOTE: The 2023 OWASP API Top 10 vulnerabilities list replaced Lack of Resources and Rate Limiting with Unrestricted Resource Consumption. See blog on Unrestricted Resource Consumption.
No. 4 on the OWASP API Top 10 vulnerabilities list is lack of resources and rate limiting (after BOLA, broken user authentication, and excessive data exposure). OWASP says of this vulnerability, “Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.”
How Do Lack of Resources and Rate Limiting Exploits Work?
Imagine that bad guys could hack into your smart thermostat and adjust the thermostat. Big deal, you might think, until you got the electric bill that month.
Imagine they could remotely open all the faucets in your house.
Imagine that they could momentarily materialize in your kitchen, open the refrigerator door, then disappear, leaving that fridge door open.
That’s kind of how #4 of the OWSP API Top 10 works.
Well-constructed API endpoints, whether as part of their software or otherwise, should keep track of who’s making calls, and thereby consuming compute resources, database sessions, or even bandwidth between the endpoint and the Internet.
But many APIs don’t keep tabs on this kind of stuff.
OWASP gives this example:
We have an application that contains the users’ list on a UI with a limit of 200 users per page. The users’ list is retrieved from the server using the following query: /api/users?page=1&size=200. An attacker changes the size parameter to 200 000, causing performance issues on the database. Meanwhile, the API becomes unresponsive and is unable to handle further requests from this or any other clients (aka DoS).
Let’s put a fine point on it – This site was just, for all practical purposes, taken down.
How to Prevent Lack of Resources and Rate Limiting
Developers have a lot of tricks at their disposal to design around this type of vulnerability. For instance, in the example above, it’s entirely reasonable to set a default upper limit to the number of results a query would return. In the example above, the endpoint maximum default could be set to 300. That’s still a very large set of results, but the hacker’s attempt to bring down the system by requesting 200,000 users per page will be thwarted.
How ThreatX Can Help
Designing protection in is always a great strategy, but realistically, enterprises don’t always even have source code for the APIs that run their business.
ThreatX identifies and flags behavior indicative of an attempt to exploit a lack of resources or rate limiting – such as high error counts – from a single entity. ThreatX can then, in real time, implement rate limiting or block the user if there are other indications of malicious behavior. We can rate limit at the endpoint, host name, or entity level.
How Our Approach Is Unique
Real-Time Blocking
Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify attacks, but require security teams to try to model the complex behavior in a third-party WAF. Or worse, they create the necessity to block one IP at a time, often after the attack has successfully DDoSed a system. ThreatX doesn’t just tell you about your API vulnerabilities. Instead, we get at root causes of these kinds of vulnerabilities – malicious and suspicious traffic – and we block those API attacks in real-time.
ThreatX recognizes attacker behavior indicative of an attempt to exploit endpoints with poor resource management or rate limiting; we then flag and watch that user. If the suspicious behavior continues, or is mingled with other sketchy behavior, then that user is blocked. The API endpoint is protected, even though it’s still vulnerable. This mitigation might be sufficient forever, or it might buy your dev teams time to remediate the vulnerability. Either way, your endpoint is still up and running.
Step One of N…
One caution on the OWASP Top 10 list of API vulnerabilities – it’s a great way to categorize vulnerabilities, but it’s not necessarily an attacker playbook. They don’t try one simple thing. They attack APIs by stringing together a series of attacks over time, often using federated and sophisticated botnets. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker.
Identifying Risk
In practice, attackers often camouflage their attempts to exploit this API vulnerability by flooding the endpoint with suspicious traffic, or simply by spraying the endpoint with benign requests.
ThreatX cuts through this deceptive traffic, and blocks potential threats before they can bleed away resources and impact your SLA with your customers. The ThreatX API Dashboard details API endpoint usage, visualizing both legitimate and malicious traffic. With this visibility, ThreatX customers can identify rate limit attacking entities, preventing denial of service.
Back to the original example… ThreatX comes along behind the bad guy and closes the refrigerator. We set that thermostat back to an energy efficient 62F. And we close the taps on the faucet before you get a $3,000 water bill.
Learn more in A Security Practitioner’s Introduction to API Attack Protection. Or request a demo of the ThreatX solution.
