GraphQL Depth-Bombing & Batch-Bypass

GraphQL's pitch is power for the client: ask for exactly the data you need, in any shape, in one round trip. The flip side is that 'in any shape' includes shapes the server didn't design for — recursive queries that fetch exponential data, alias batching that turns one HTTP request into a hundred logical operations, introspection that publishes the entire schema. Each of those features has a defensible motivation in the GraphQL spec; each is also a vulnerability vector when the server doesn't enforce limits. Modern GraphQL servers (Apollo Server 4+, Yoga, Hasura) ship reasonable defaults, but plenty of older deployments still ship with introspection on, no depth limit, and no per-alias rate limiting.

GraphQL weaknesses appear when schema access, query cost, or resolver authorization is too permissive. Attackers can use the API's flexibility to discover data or stress expensive paths.

DoS via depth bomb is straightforward — server falls over from one expensive request, or from a small number of repeated ones. Auth rate-limit bypass via alias batching turns 'we limit logins to 5/min' into 'we limit batches of 100 logins to 5/min,' i.e., 500/min effective. Schema disclosure via introspection or field suggestions is mostly recon impact, but combined with authorization mistakes it becomes the recipe for surgical data extraction. In multi-tenant deployments, knowing the exact schema lets the attacker craft tenant-traversal queries.

Set a max query depth — 8 or 10 levels is generous for legitimate use cases and tight enough to defeat exponential queries. Use libraries like `graphql-depth-limit`. Add complexity analysis (`graphql-cost-analysis`, `graphql-rate-limit`) that scores each query and rejects above a threshold — depth alone misses some cases. Disable field-suggestion responses in production (Apollo: `formatError` to strip suggestions; Yoga: maskedErrors plugin). Disable introspection in production (Apollo: `introspection: false` in config). Apply rate limiting per-alias, not per-request — each aliased login mutation should count as a separate operation against the limiter. Cap query body size at the HTTP layer — most legitimate queries fit in 8KB; a 1MB query is suspicious. For mutations, require an `Idempotency-Key` so the same operation can't be replayed in batches.