GraphQL HTTP Batching Enabled
ID |
graphql_batching_enabled |
Severity |
low |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Family |
API4:2023 - Unrestricted Resource Consumption |
CWE |
CWE-770 |
Resource |
configuration |
Language |
any |
Description
Fires once per GraphQL service when the server explicitly opts into batched HTTP requests — Apollo Server 4 allowBatchedHttpRequests: true or graphene/Django GraphQLView(batch=True) — allowing one HTTP request to carry an array of GraphQL operations.
This is a positive-polarity check: only explicit opt-ins are flagged; frameworks that batch by default are not guessed at, keeping the finding low-noise.
Rationale
Batching multiplies the cost of every other GraphQL weakness: one HTTP request can carry N brute-force login mutations, N deep queries, or N object-id probes — and it slips under rate limits and WAF rules that count HTTP requests rather than GraphQL operations. Batched credential-stuffing against GraphQL login mutations is a documented real-world technique. OWASP API4:2023 — Unrestricted Resource Consumption (CWE-770).
Remediation
If batching is not required, remove the opt-in (allowBatchedHttpRequests: true / batch=True).
If batching is required:
-
cap the batch size (a GraphQL Armor-style
maxBatchSizeguard, or a body-size limit at the proxy) -
rate-limit by operation count, not by HTTP request
-
keep a per-query depth/complexity ceiling so a batch cannot multiply an already-expensive query.