The Unrestricted Resource Consumption vulnerability has replaced Lack of Resources and Rate Limiting in the OWASP API Security Top 10, but, although the name changed, the vulnerability remains the same overall.
API requests consume resources such as network, CPU, memory, and storage. The number of resources required to satisfy a request greatly depends on the input from the user and the business logic of the endpoint.
APIs do not always impose restrictions on the size or number of resources that can be requested by the client or user, creating security vulnerabilities that can not only impact the API server performance, leading to Denial of Service (DoS), but also leave the door open to brute-forcing and enumeration attacks against APIs that provide authentication and data fetching functionality. This includes automated threats like credential cracking and token cracking, among others.
When determining the potential impact of Unrestricted Resource Consumption – number four in the OWASP API Security Top 10 -, it is best to break down the impact of this issue into two sub-components:
In the example above of a lack of resource limit, the attacker has increased the max_return and page_size values for the search filter from 250 to 20,000. This increase would cause the application to return an excessive number of items in response to a query. It could also cause the application to slow down or become unresponsive for all users.
A very popular example of this type of attack are distributed denial-of-service (DDoS) attacks targeting APIs. One recent example shows how Poland’s key tax portal was rendered unavailable to Polish citizens due to an attack of this category, where hackers were able to exploit the resources that support the APIs behind the central tax service and make it unavailable for several hours.
With Polish government officials quickly pointing the finger at Russian hackers, in light of the Ukraine war, this attack comes to show how today’s social and political landscape makes cybersecurity, and API security in particular, even more crucial for businesses and government institutions alike.
Traditional security controls like WAFs, API gateways, and other proxying mechanisms will commonly offer basic or static rate limiting which are difficult to enforce at scale. Security teams may not know enough about the application design to know what “normal” looks like to enforce limits to thwart attackers while not impacting business functionality. WAFs and API gateways lack the context required to inform security teams on what a normal value should be for an API parameter, and they will miss attacks where an attacker manipulates a single API parameter value to overwhelm the application. These proxies may also only cover ingress, or inbound requests, as opposed to egress traffic, or outbound requests and responses.
An API security solution must be able to identify calls to API endpoints and alterations to API parameter values that fall outside of normal usage. This would be done by analyzing all API traffic to create a baseline of typical behavior and identifying deviations that fall outside of that baseline.
In the example above an API security solution will have created a baseline of values for the max_return and page_size parameters and will identify that a value of 20,000 is abnormal. The solution could then alert on and block an attacker who crafts API requests that deviate from the baseline.