Unrestricted Resource Consumption (API4:2023) is the only threat category in the OWASP API Security Top 10 explicitly dedicated to Denial of Service (DoS) and resource abuse. But despite being just one category, attackers can exploit it in many different ways; from large file uploads and expensive GraphQL queries to abuse of metered third-party services like SMS gateways or AI/LLM APIs. These attacks can lead not only to performance degradation and service unavailability, but also to direct financial losses.
In this post, we explore 8 real-world attack scenarios that fall under API4 and show how Wallarm detects and mitigates each of them using a layered, adaptive approach.
Scenario 1: Uploading a Large File
Attack Vector: An attacker sends a massive file to an upload endpoint (e.g., image, video, or document upload) that forces the backend to consume excessive memory or disk space during processing.
Business Scenario: An e-commerce platform that allows users to upload product images is targeted. The attacker uploads multi-GB files, repeatedly triggering memory exhaustion and slowing down the application for all users.
Wallarm Mitigation:
- Mitigation Control: File Upload Restriction Policy enforces maximum total request size and per-parameter size (e.g., image) directly on the filtering node, blocking oversized requests before they reach the app.
- API Abuse: Unrestricted Resource Consumption Detection detects traffic patterns involving consistently large payloads and flags abnormal sessions.
Scenario 2: High-Latency Responses
Attack Vector: An attacker identifies resource-heavy API endpoints—like report generation, PDF export, or analytics queries—and bombards them to spike server response times.
Business Scenario: Attackers target a SaaS reporting tool by repeatedly triggering expensive report generation jobs via API, causing delays and timeouts for legitimate users.
Wallarm Mitigation:
- API Abuse: Unrestricted Resource Consumption Detection monitors response time anomalies and applies adaptive thresholds to detect abusers. Offending sessions can be automatically throttled or blocked.
Scenario 3: Excessive Response Size (Data Exfiltration)
Attack Vector: The attacker sends crafted requests that return unusually large responses, aiming to slowly extract large datasets or internal information.
Business Scenario: A fintech app exposes customer transaction data via a search API. Attackers exploit it by incrementally querying massive datasets and collecting large responses over time.
Wallarm Mitigation:
- API Abuse: Unrestricted Resource Consumption Detection identifies unusually large outbound data streams and flags those sessions as potential scraping or exfiltration attempts.
Scenario 4: Financially Impactful API Abuse (e.g., SMS Gateways, Metered Services)
Attack Vector: An attacker targets APIs that trigger costly or third-party operations (e.g., sending SMS, initiating transactions) to drive up costs and deplete backend capacity.
Business Scenario: A mobile app offers 2FA via SMS through an API. Attackers automate requests to spam the SMS endpoint, draining API quotas and increasing operational costs.
Additional Example: An AI platform exposes a prompt-handling API backed by a paid LLM provider. Attackers script repeated prompt submissions, unintentionally or intentionally triggering high-cost processing and inflating third-party bills.
Wallarm Mitigation:
- Mitigation Control: DoS Protection detects excessive rates of requests that match specific criteria within a user session—such as repeated access to sensitive or costly endpoints
Scenario 5: Rate Limit Bypass via GraphQL Batching
Attack Vector: GraphQL supports batching, allowing multiple queries or mutations to be packed into a single HTTP request. Attackers abuse this feature by bundling many operations into one call to bypass rate-limiting mechanisms that operate on a per-request basis. While traditional rate-limiters only see one HTTP request, each batched query consumes processing time, memory, and I/O. This allows attackers to perform brute-force, scraping, or denial-of-service actions at scale, under the radar.
Business Scenario: A social media API allows querying multiple user profiles. By batching dozens of queries in one request, attackers extract large volumes of data while staying under rate-limiting thresholds.
Wallarm Mitigation:
- Mitigation Control: GraphQL API Protection allows setting strict limits on batched operations per request, preventing attackers from overloading logic layers with excessive GraphQL actions.
Scenario 6: GraphQL Query Abuse (Nested Queries, Alias Overload)
Attack Vector: GraphQL’s expressiveness allows deep query nesting and extensive use of aliases. Attackers exploit this by sending queries with extreme recursion depth or hundreds of aliases, forcing the backend to execute many redundant operations. Each alias can trigger a costly resolver execution, and deep nesting may multiply traversal logic. These seemingly valid queries can tie up CPU and memory, significantly slowing down or crashing services.
Business Scenario: An online learning platform uses GraphQL for content delivery. An attacker crafts deeply nested queries that cause recursive backend processing and overwhelm compute resources.
Wallarm Mitigation:
- Mitigation Control: GraphQL API Protection enforces:
- Maximum Query Depth to limit recursion levels
- Maximum Aliases per Request to prevent alias spamming and logic abuse
Scenario 7: Data Bomb (Payload Expansion Attacks)
Attack Vector: Attackers craft small payloads that expand massively during processing. Examples include zip bombs (archives that decompress into gigabytes), deeply nested JSON structures, or XML payloads using recursive entity references. These payloads often bypass basic input validation due to their small size but cause massive resource allocation once parsed, leading to memory exhaustion, slowdowns, or full application crashes.
Business Scenario: A file-sharing API accepts compressed files. An attacker uploads a zip file containing recursive directories or massive decompression footprint, consuming gigabytes of memory during extraction.
Wallarm Mitigation:
- Real-Time Detection with deep parsing of requests identifies payloads that behave abnormally when processed (e.g., excessive decompression rate) and blocks them before damage is done.
Scenario 8: Denial of Service via Buffer Overflow Attacks
Attack Vector: The attacker crafts oversized input for a specific parameter, attempting to trigger memory corruption, buffer overflow, or unsafe parsing behaviors.
Business Scenario: A notable real-world example is CVE-2025-22457, a critical stack-based buffer overflow vulnerability affecting Ivanti Connect Secure VPN appliances, where oversized HTTP headers can be exploited to corrupt memory and cause system failure.
Wallarm Mitigation:
- Mitigation Control: File Upload Restriction Policy can be used as a virtual patch by limiting the exact size of parameters vulnerable to overflow (for example headers). This prevents malformed requests from executing dangerous memory operations.
Conclusion: One Threat, Many Faces — and Full Coverage
Denial of Service attacks aren’t just volumetric anymore. Attackers now exploit business logic, API design, and backend behavior to drain resources quietly and persistently. That’s the danger behind OWASP API4:2023 – Unrestricted Resource Consumption: a single category that unlocks many abuse vectors—from file uploads and deeply nested queries to financial drain via costly API integrations.
Wallarm addresses this evolving threat landscape with a combination of real-time mitigation on the node and adaptive detection in the cloud. Whether the abuse is technical, behavioral, or financial, Wallarm’s tools detect it, analyze it, and stop it in its tracks.
With the introduction of File Upload Restriction Policy and Unrestricted Resource Consumption Detection—alongside our full API Abuse and DoS protection suite—you gain broad, deep, and intelligent coverage against every known variation of API4:2023 exploitation.
The post Exploiting API4 — 8 Real-World Unrestricted Resource Consumption Attack Scenarios (and How to Stop Them) appeared first on Wallarm.