GraphQL Batching Attacks: The DoS Vector Hiding in Plain Sight

In March 2026, a fintech startup running a GraphQL API discovered their authentication endpoint was processing 50,000 login attempts per second—all from a single IP address. Their WAF showed nothing unusual. Rate limiting was "working." But attackers weren't sending 50,000 HTTP requests. They were sending one.

Welcome to the world of GraphQL batching attacks, where the flexibility that makes GraphQL powerful becomes its greatest vulnerability.

GraphQL's batching feature was designed to solve the N+1 query problem. Instead of making multiple HTTP round trips, clients bundle operations into a single request:

[
  {"query": "query { user(id: 1) { name } }"},
  {"query": "query { user(id: 2) { name } }"},
  {"query": "query { user(id: 3) { name } }"}
]

The server processes them sequentially, returning an array of results. Elegant, efficient—and absolutely devastating when weaponized.

Attackers quickly realized that most rate limiters count HTTP requests, not GraphQL operations. A single POST request containing 100 login attempts looks like one request to your infrastructure but executes as 100 authentication attempts against your database. Standard WAF rules don't inspect JSON payloads for nested query arrays. IP-based blocking becomes meaningless when the "attack volume" shows up as 10 requests per minute.

Disabling batching doesn't solve the problem. Attackers have multiple vectors to achieve the same outcome:

Alias Overloading When batching is disabled, aliases provide an alternative path:

query {
  user1: user(id: 1) { name email }
  user2: user(id: 2) { name email }
  user3: user(id: 3) { name email }
  # ... repeat 100 times
}

The server processes each alias as a separate resolver invocation. One request, N operations.

Field Duplication Even simpler—duplicate fields force redundant computation:

query {
  user(id: 1) {
    name
    name
    name
    # repeated 50 times
  }
}

Some GraphQL implementations deduplicate response fields but still execute the resolvers, wasting CPU and database connections.

Circular Fragments GraphQL fragments are client-controlled and can create circular references that expand exponentially:

fragment UserFields on User {
  friends {
    ...UserFields
  }
}

query {
  user(id: 1) {
    ...UserFields
  }
}

Without depth limiting, this query recursively traverses relationships until resource exhaustion crashes the server.

Protecting GraphQL requires moving beyond traditional HTTP-centric security models. Here's a practical defense strategy:

1. Query Complexity Analysis

Assign cost scores to fields and reject queries exceeding thresholds:

# Python example using graphql-cost-analysis concepts
COMPLEXITY_LIMIT = 1000

field_costs = {
    'User': {'friends': 10, 'orders': 5},
    'Order': {'products': 5, 'shipping': 1},
}

def calculate_complexity(query_ast):
    total = 0
    for field in query_ast.selections:
        cost = field_costs.get(field.type, {}).get(field.name, 1)
        total += cost * calculate_complexity(field)
    return total

2. Depth Limiting

Prevent circular and deeply nested queries:

// Node.js using graphql-depth-limit
const depthLimit = require('graphql-depth-limit');
const { createYoga } = require('graphql-yoga');

const yoga = createYoga({
  schema,
  validationRules: [depthLimit(10)]  // Max 10 levels deep
});

3. Operation-Level Rate Limiting

Count GraphQL operations, not HTTP requests:

# Example Envoy proxy configuration
rate_limits:
  - actions:
      - request_headers:
          header_name: "x-graphql-operation-count"
          descriptor_key: "graphql_ops"
    limit:
      unit: minute
      requests_per_unit: 50  # Max 50 operations per minute

4. Persistent Query Whitelisting

Only allow pre-registered queries in production:

// Using @apollo/persisted-query-lists
const { PersistedQueryList } = require('@apollo/persisted-query-lists');

const allowList = new PersistedQueryList({
  queries: require('./query-manifest.json')
});

GraphQL's flexibility is a double-edged sword. The same features that make it developer-friendly—batching, nested queries, client-specified fields—create attack surfaces invisible to traditional security tooling. Standard WAFs, IP-based rate limiting, and HTTP-centric monitoring won't save you.

The vulnerabilities disclosed in early 2026—including Check Point Research's findings on Claude Code's API key exfiltration and the ongoing GraphQL DoS campaigns targeting fintech—demonstrate that attackers are actively exploiting these gaps.

Audit your GraphQL APIs today:

• Review rate limiting logic—are you counting operations or requests?
• Test query complexity limits with real attack patterns
• Disable introspection and GraphiQL in production
• Implement persistent query whitelisting
• Monitor for alias-heavy queries and field duplication

Your next breach might come in a single POST request containing a thousand malicious operations. Make sure you're counting what matters.