GraphQL Batching Lab: Brute-Force Past a Rate Limit in One Request

This article explains how GraphQL batching can defeat rate limits designed to count HTTP requests rather than individual operations. By bundling multiple login attempts into a single POST request using aliases or array batching, an attacker can bypass login attempt throttling that caps five attempts per minute. The vulnerability exists because rate limiters often count requests as the unit of control, while GraphQL allows arbitrary numbers of operations within a single request.

• How GraphQL batching defeats request-based rate limitsGraphQL allows multiple operations to be bundled into one HTTP request through aliasing (the same field repeated under different names) or array batching (several operations in one payload). If a rate limiter counts requests rather than operations, a single POST containing 100 login mutations counts as one request, allowing an attacker to execute many password attempts while the counter registers only one.
• The GraphqlAPI lab demonstrates credential brute-force bypassThe lab presents a scenario where GraphqlAPI enforces a five-per-minute login limit per HTTP request. An attacker constructs a single GraphQL POST with many aliased login mutations, each trying a different candidate password for the admin account, sends it once, and inspects the batched response to identify which aliased mutation succeeded, effectively bypassing the rate limit.
• Attack requires confirming per-request rate limit designThe attack approach begins by confirming that the login rate limit is enforced per HTTP request, not per operation. Only systems that count requests rather than operations are vulnerable to this batching bypass technique.
• Fundamental design flaw in rate limit boundariesThe rate limit guards the wrong boundary by assuming one attempt per request, which holds true for traditional form-based login but fails for GraphQL where a single request carries an arbitrary number of operations. The counter never rises because the entire batch appears as one request to the limiter.
• Real-world impact on authentication and configurationBatching and alias-based rate-limit bypass enables credential brute-force and OTP bypass attacks. The vulnerability maps to Identification and Authentication Failures (A07) and Security Misconfiguration (A05) in the OWASP Top 10 (2021), and is well-known across many GraphQL frameworks that enable batching with naive per-request throttling.
• Defend by counting operations instead of requestsRate-limit per operation by counting every mutation or query inside a request rather than the request itself. Additionally, limit batch size and query depth or cost to reject requests bundling too many operations, apply account-specific throttling independent of transport, and consider disabling array batching if the API does not require it.
• Testing technique for rate limit verificationOn an authorized GraphQL target, test by aliasing a sensitive mutation many times in one request. If a per-request rate limit allows all attempts through, the throttling is counting requests rather than operations, confirming the vulnerability.

Bottom line: Rate-limit controls for GraphQL must count individual operations and apply throttling per operation, batch size, and query cost—not per HTTP request. Naive per-request rate limiting is fundamentally broken for GraphQL and enables attackers to execute credential brute-force and other attacks that the limit was designed to prevent.