Home / Knowledge hub / GraphQL batching abuse
Knowledge hub
GraphQL batching abuse
Packing many operations into one request to dodge rate limits.
What it means
GraphQL lets a client bundle work into a single HTTP request. A client can send an array of operations together, or place many copies of a field in one query using aliases. Batching abuse is using that to do hundreds of things while the server counts one request.
Most rate limits count requests, not operations. If the limit is ten requests a minute, a single request carrying a hundred sign-in attempts slips under it without anyone noticing. The server did what it was told, many times over, in one go.
Why it matters
The usual targets are the actions that depend on a request limit: password guesses, one-time code guesses, coupon checks and lookups of who has an account. A limit that was meant to stop brute force stops nothing if every guess travels in the same envelope.
The effect is quiet and easy to miss. Logs show a few ordinary-looking requests, alerts do not fire, and the account lockout counters may never rise. By the time anyone notices, a code has been guessed or a customer list has been confirmed, and the limit you relied on never triggered.
How it shows up
You meet it wherever a GraphQL endpoint sits behind limits designed for REST. Check three things: can you send several operations in one request, can you repeat the same sensitive field many times with aliases, and does the limit count each operation or only the request?
Fixes are practical. Count operations and aliases against the limit, cap batch size and query depth, apply tighter limits to sensitive mutations such as sign-in and code checks, and lock accounts on failed attempts, not on request count. Test with a real bundle, not only a single call. See rate limiting.
Questions people ask
GraphQL batching abuse, answered
What is the difference between batching and aliasing?
Batching sends several separate operations in one HTTP request, usually as a JSON array. Aliasing renames repeated fields inside a single operation so they can be asked many times at once.
Both reduce the number of requests while keeping the number of actions high.
Is batching a vulnerability?
No, it is a legitimate feature that clients use to save round trips. It becomes a problem when limits and lockouts ignore it.
The finding is the bypass of a control, shown with a working example.
Can a WAF stop GraphQL batching abuse?
Rarely on its own. A WAF mostly sees one ordinary POST request and may not read operations inside the body.
Limits need to be applied by something that understands GraphQL, or in the resolver logic.
Which endpoints should be protected first?
Start with sign-in, password reset, code verification, voucher or gift card checks, and any lookup that confirms whether a record exists.
These are the places where speed of guessing is worth money to an attacker.
Should we turn batching off?
If your clients do not use it, yes, that is simplest. If they do, keep it but cap the size and count every operation.
Either way, confirm it with a test after the change.
Related
Terms that sit next to this one
GraphQL
One API endpoint where the client asks for exactly the fields it wants.
Rate limiting
Capping how often something can be attempted, per user or per address.
API rate limiting
Capping how many calls a client can make so abuse and cost stay bounded.
Brute force
Trying passwords or codes over and over until one of them works.
Limit overrun
Exceeding a cap, such as one redemption per customer, with parallel requests.
Does your limit count the contents?
Limits that count requests miss what is packed inside them. We test whether sign-in, codes and other sensitive actions hold up against bundled requests, and show the exact request. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.