GraphQL hardening: query cost, depth and federation

Why GraphQL needs hardening that REST does not

In REST, the server owns the shape of every response. GET /users/42/friends returns a bounded page; the cost of that endpoint is fixed and known when you write it. The client cannot ask /users/42/friends/friends/friends — there is no such route, and to get nested data the client must make more, separately rate-limitable, requests.

GraphQL inverts this. The client composes the query, choosing the fields, the depth, and the width in a single request. That expressiveness is the selling point, and it is also the attack surface: a client can ask for arbitrarily deep, arbitrarily wide, recursive data in one HTTP call, and the server will dutifully resolve it. A self-referential type like User.friends: [User] lets a query nest into itself until the response is a combinatorial explosion. One request, no auth required, becomes millions of resolver calls and DB hits. That is a denial-of-service vector unique to exposing a GraphQL endpoint, and it is why a public GraphQL API needs execution guards that a REST API gets for free from its fixed routes.

The defense is layered, and the layers run before execution — you reject the malicious query during validation, not by surviving it.

Control 1 — depth limiting

The first guard caps how deeply a query may nest. A validation rule walks the query AST and rejects any operation whose selection set is nested past a maximum — typically 7 to 10 levels for a real application. This is what stops the recursive-friends bomb: friends { friends { friends { ... } } } exceeds the depth limit and is rejected during validation, before a single resolver runs.

// main.ts — wire a depth-limit validation rule into Apollo's validationRules
import depthLimit from 'graphql-depth-limit';

GraphQLModule.forRoot<ApolloDriverConfig>({
  driver: ApolloDriver,
  // any operation nested deeper than 7 selection sets is rejected at validation
  validationRules: [depthLimit(7)],
});

Depth limiting is cheap, static, and catches the most obvious recursion. But it has a blind spot, and that blind spot is the next control.

Control 2 — query complexity / cost analysis

A query can be shallow and still ruinous. users(first: 10000) { posts(first: 1000) { comments(first: 1000) } } is only three levels deep — it sails past any depth limit — yet it multiplies to roughly ten billion nodes. Depth limiting counts nesting; it is blind to width and to pagination multipliers.

Cost analysis fixes this. You assign a numeric complexity to each field — scalar fields are cheap, list fields are expensive, and a list field’s cost is multiplied by its pagination argument — then sum the cost of the whole query before execution and reject anything over a budget (commonly 1000). NestJS supports this through a complexity plugin that computes a score against per-field estimators or a complexity value on the field.

// Annotate the expensive field, and multiply by the pagination arg
@Field(() => [Post], { complexity: 5 })
posts: Post[];

// A plugin sums the query's complexity at validation time and rejects over budget
import { ComplexityPlugin } from './complexity.plugin'; // computes score, throws over maxComplexity (e.g. 1000)

The estimator for a paginated list multiplies the field’s base cost by first/limit, so users(first: 10000) scores 10000× the per-user cost and blows the budget on its own. This is the control that catches the wide-but-shallow bomb a depth limit waves through. You need both: depth for recursion, cost for fan-out.

Control 3 — persisted queries (the strongest lever)

The previous two controls bound an arbitrary query. Persisted queries change the game by removing arbitrariness. Instead of accepting any query string, the client sends a hash of a query that was registered ahead of time; the server looks up the hash and runs only the operation it already knows. Automatic Persisted Queries (APQ) do this primarily to shrink request payloads — the client sends a short hash instead of a long query string.

The security win comes from running persisted queries in allow-list mode: the server executes only operations from a vetted, pre-registered set, and rejects any hash it has not seen. In that mode arbitrary-query DoS is eliminated outright — an attacker cannot send the recursive-friends bomb because the server will not run a query it was not given at build time. The tradeoff is flexibility: a public or third-party API whose clients legitimately compose novel queries cannot allow-list them. For a first-party app — your own web and mobile clients shipping a fixed, known set of operations — allow-listed persisted queries are the single strongest hardening lever, and they compose with depth and cost limits as defense in depth.

The runtime cousin: N+1 and DataLoader

Cost analysis bounds what the client can ask for; it says nothing about what your resolvers actually do while answering. A resolver fan-out re-introduces the N+1 problem — resolving a list of N parents and then firing one child query per parent — which (as covered earlier in this unit) DataLoader solves by batching the N reads into one and caching per request. Think of them as a pair: cost limiting is the static budget on the request shape, DataLoader is the runtime budget on resolver work. A hardened API needs both, because a query that passes the cost gate can still issue N+1 queries if its resolvers are naive.

Federation — when the single graph is the bottleneck

The controls above protect one graph. Have you ever had to wait for another team’s schema review before shipping your own type? That’s the ownership mess federation is built to dissolve. As the graph grows, a single monolithic schema and resolver set becomes a deploy bottleneck — every team editing one file, every change a full redeploy. Apollo Federation (in NestJS, the ApolloFederationDriver) splits the graph across services. Each subgraph owns its own types, marks the entities it owns with @key(fields: "id"), and provides a __resolveReference resolver so other subgraphs can extend its entities by reference. A gateway composes the subgraphs into one supergraph and plans cross-service queries, fetching each entity’s fields from the subgraph that owns them.

# users subgraph — owns the User entity, identified by id
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# reviews subgraph — extends User by reference, adds the fields it owns
type User @key(fields: "id") {
  id: ID! @external
  reviews: [Review!]!   # resolved here via __resolveReference(id)
}

This is the modern, declarative successor to older schema stitching, where a gateway manually merged schemas and you wrote the cross-service wiring by hand. Federation makes the relationships declarative — @key and __resolveReference — and lets the gateway plan the query. Crucially, hardening does not move to the gateway and stop there: depth limits, cost analysis, and persisted queries still belong at the edge, because the supergraph is exactly as composable — and therefore exactly as abusable — as the single graph it replaced.