GraphQL Query DoS: Depth, Cost & Batch Limits

Core Concepts & Key Terms

Query depth

The maximum number of nested field levels in an operation. Depth does not measure how many objects a list field returns.

Query cost / complexity

A server-side estimate of resolver and data-source work, weighted by field behavior and list-size arguments, checked before execution.

Batch and breadth limits

Controls on operations per transport batch, top-level fields, aliases, or repeated selections. Enforce them at the request integration.

Schema introspection

Schema-discovery fields such as __schema and __type. Restricting them can reduce schema exposure but does not itself stop expensive operations.

How GraphQL Resource-Exhaustion Requests Work

Scope: Introspection is not required to submit costly queries; a client may already know the schema. This is a vulnerability class, not a specific CVE claim.

JavaScript / Apollo Server: Unbounded Operations vs. Guarded Validation

// Vulnerable configuration: no application-specific demand controls.
import { ApolloServer } from "@apollo/server";

const server = new ApolloServer({
  typeDefs,
  resolvers,
  // Introspection is not what makes an expensive operation execute.
  introspection: true
});

// Apollo Server example with graphql-depth-limit installed.
import { ApolloServer } from "@apollo/server";
import depthLimit from "graphql-depth-limit";

const isProduction = process.env.NODE_ENV === "production";
const server = new ApolloServer({
  typeDefs,
  resolvers,
  // Schema-discovery policy, not a DoS control.
  introspection: !isProduction,
  validationRules: [depthLimit(8)],
  // Bound recursive fragment expansion before custom rules.
  maxRecursiveSelections: 10_000
});

// Also enforce pagination/argument caps, a cost budget,
// adapter-level batch-size limits, and execution timeouts.

Engineering Hardening Checklist

Depth and recursive-selection rules do not estimate database work by themselves. A shallow query can request enormous lists or alias an expensive resolver repeatedly. Set pagination caps, use schema-aware cost weights, limit batch operation count in the HTTP integration, and apply timeouts and per-user or per-key budgets. Disable introspection only if the product does not need it; this reduces schema discovery, not execution cost.

• Set a depth limit and a separate bound for recursive fragment expansion; tune both against legitimate operations.
• Require pagination on list fields and clamp client-supplied limits to server-side maxima.
• Estimate operation cost using resolver and list-size behavior; reject over-budget operations before execution.
• Limit operations per transport batch and account for operation cost in rate limits; also use timeouts and concurrency controls.
• Treat introspection as a schema-disclosure choice, not a denial-of-service defense; review it separately.

• GraphQL.org — Security: depth, breadth, batching and query cost
• OWASP GraphQL Cheat Sheet — DoS and batching controls
• Apollo Server API — validationRules and maxRecursiveSelections