Introduction
Imagine your application is an all-you-can-eat restaurant…
Most customers take a reasonable amount of food, but one person decides to empty every single tray.
The kitchen can't keep up, the food runs out, and every other customer is left waiting. This scenario explains what happens in the digital world with Unrestricted Resource Consumption, a major vulnerability listed as API4:2023 in the OWASP API Security Top 10.
This vulnerability occurs when an API fails to limit the resources a client can request, and attackers can exploit this by making requests that consume excessive memory, CPU, network bandwidth, or other resources, leading to performance degradation and, ultimately, a Denial of Service (DoS) that makes your application unavailable to legitimate users.
The High Cost of No Limits
Failing to control resource consumption can have severe consequences for your business, including:
- Denial of Service (DoS): The most direct impact. By overwhelming your servers with resource-heavy requests, an attacker can crash your application or make it so slow that it becomes unusable for everyone.
- Denial Of Inventory (DoI): This business logic attack targets e-commerce and reservation systems. Automated bots add all available stock of a high-demand item to multiple shopping carts, holding them without ever completing the purchase. As a result, the item appears as 'out of stock' to legitimate customers, preventing them from buying and directly leading to lost revenue and customer frustration.
- Skyrocketing Operational Costs: In a cloud environment, resource exhaustion can trigger auto-scaling events, leading to a sudden and massive increase in your infrastructure bills. An attacker could effectively weaponize your cloud spending against you also known as “Economic Denial of Sustainability (EDoS).
- Degraded User Experience: Even without a malicious attack, a few power users or poorly designed client applications making heavy requests can slow down the service for all users, leading to frustration, support tickets, and potential customer churn.
How Unrestricted Resource Consumption Happens: Common Scenarios
Attackers often exploit a lack of limits to exhaust critical business or infrastructure resources. Here are two real-world examples:
1. Denial of Inventory: The "Sold Out" Flight
Most airline and ticketing websites temporarily reserve a seat for 15 minutes when a user selects it, allowing time for payment. A legitimate request looks like this: POST /api/v3/flights/hold-seat (user: "traveler_01", flight: "RW789", seat: "12A")
But what if a bot programmatically "holds" every empty seat on the plane?
POST /api/v3/flights/hold-seat (user: "bot-xyz", flight: "RW789", seat: "12A")
POST /api/v3/flights/hold-seat (user: "bot-xyz", flight: "RW789", seat: "12B")
POST /api/v3/flights/hold-seat (user: "bot-xyz", flight: "RW789", seat: "12C")
...and so on for the entire cabin.
By refreshing these holds just as they expire, the attacker ensures the flight appears "Sold Out" to real customers. This business logic attack directly kills revenue without ever crashing the server.
Denial of Service: Search Abuse
Search features often require complex database queries that consume significant CPU. A standard user search is harmless: GET /api/v1/catalog/search?query=headphones
However, an attacker can send "wildcard" or complex queries designed to force the database into a maximum-load calculation:
GET /api/v1/catalog/search?query=%
GET /api/v1/catalog/search?query=a*b*c*... [Complex Regex]
Without limits on query complexity, a few dozen of these requests can pin the database CPU to 100%, slowing down or crashing the entire application for all users.
Why Relying on Code Isn't Enough
While fixing vulnerabilities in the code is important, relying on it exclusively leaves significant security gaps. An external security solution provides better coverage, capable of handling complex protections and detecting attack obfuscations that standard code checks often miss. Furthermore, security rules in code are based on expectations, whereas external solutions react to real traffic patterns.
There is also a practical reality: developers often rely on 3rd-party libraries they don't own or control, making it impossible to patch every vulnerability directly. Finally, secure coding requires specialized expertise; expecting every developer to master the complexities of Web, API, and Cloud security is unrealistic. A dedicated solution bridges this gap, ensuring robust protection without overburdening your development team.
How Radware Protects Unrestricted Resource Consumption
Protecting against resource consumption attacks requires a multi-layered defense that can enforce limits at different stages of the request.
Radware’s Web Application and API Protection (WAAP) solution provides a comprehensive toolkit to mitigate these threats before they can impact your backend services.
1. Business Logic Attack Protection
Our Business Logic Attack Protection is the most advanced API defense available, uniquely capable of stopping the Denial of Inventory attacks described above. Unlike traditional rate limits that only count how fast someone is clicking, this solution employs Sequence Protection to validate the entire user journey. It ensures that every request follows the legitimate, expected business flow.
In the Flight Reservation case, a bot typically attempts to hit the "hold-seat" API endpoint directly to lock up inventory as fast as possible. Radware’s solution effectively blocks this by verifying that the user first completed the necessary preceding steps—such as searching for the flight and selecting an itinerary. Because the bot skips these required logical steps, it is instantly identified as malicious and blocked.
Because this method relies on strict adherence to your application's specific logic rather than generic traffic thresholds, it prevents these attacks with no false positives. This ensures that legitimate travelers always have seamless access to book their flights, while abusive automation is neutralized before it can impact your revenue.
2. Rate Limiting
The first line of defense is controlling the volume of traffic hitting your web application. Radware allows you to easily enforce granular rate limits based on various parameters like Method and Path combined with a Client Identifier definition for more accurate measuring. Beyond specific endpoints, Site-wide rate limiting can also be configured for a more comprehensive approach, offering granularity from the endpoint level up to the entire site to cover all your rate limiting needs.
In the context of Search Abuse, this capability is critical. An attacker relies on sending a high volume of complex queries to exhaust your CPU. By enforcing a strict rate limit on the search endpoint (e.g., GET /api/v1/catalog/search), you effectively neutralize the attack. Even if a malicious user attempts to send heavy wildcard queries, the rate limit ensures they cannot send enough of them to impact your database performance, keeping the application fast and responsive for legitimate users.
3. Behavioral and Automated Layer 7 DDoS Protection
Radware’s behavioral algorithms learn the normal traffic patterns of your application (with more than 60 indicators) and can automatically detect anomalies that signal a resource consumption attack like no other.
This allows detecting and mitigating distributed, bot-driven, and other advanced DoS/DoI attacks targeting your application in real-time and getting detailed visibility to Web-DDoS attacks.
Zero configuration – Prolific protection.
4. Client-Side Protection
Resource-consumption attacks often originate from compromised browsers or automated client-side scripts. Radware’s Client-Side Protection actively secures the user's browser environment to prevent these threats at the source. By monitoring and validating the integrity of the code running in the client’s browser, this solution detects and stops malicious script injections or unauthorized third-party code that might hijack a legitimate user's session to send flood requests. This protection effectively mitigates the attack before the traffic ever leaves the client device, significantly reducing the load on your infrastructure by ensuring only legitimate, clean traffic reaches your backend.
*Client-Side Protection is not practical for a machine-to-machine Web API application
5. Token Control & Authorization
Many resource exhaustion attacks exploit authenticated sessions where the user is valid, but their behavior is excessive or unauthorized for specific high-cost endpoints.
Radware’s Token Control enforces strict governance over API access tokens (such as JWTs) to prevent their misuse.
Instead of simply checking whether a user is logged in, this feature validates the specific permissions and claims within the access token for every request, allowing it to instantly block requests from tokens that show signs of abuse, theft, or replay attacks.
By validating authorization at the edge, Radware prevents unauthorized users from triggering resource-intensive processes, reducing unnecessary strain on your backend servers.
Conclusion
Unrestricted Resource Consumption is a silent but potential threat that can hit application availability and drive-up costs.
While developers should strive to build resilient code, relying solely on application-level fixes is a risky and incomplete strategy.
A dedicated security layer is essential to enforce consistent boundaries and protect your services. Radware’s integrated WAAP solution offers a robust, multi-layered defense against resource consumption attacks.
With Radware, you gain the visibility and control needed to ensure your APIs remain available, performant, and secure. Let us help you set the right boundaries and defend your applications from being pushed beyond their limits.