GraphQL-Specific Risks: Depth, Cost and Introspection

A REST endpoint gives you exactly the response shape its author decided to return, and nothing else — the server controls the cost of every request because the server wrote the query. GraphQL inverts that relationship: the client writes the query, nesting fields as deep and as wide as the schema allows in a single round trip, and the server has to resolve whatever shape arrives. That flexibility is the entire reason teams adopt GraphQL, and it is also why a GraphQL endpoint fails in ways a REST endpoint structurally cannot — a single syntactically valid query can ask the resolver to walk a friends-of-friends-of-friends graph five levels deep, or request the same expensive field ten thousand times under ten thousand aliases, and the server will try, because nothing in the protocol stops it.

Two failure modes follow directly from that inversion. The first is resource exhaustion: a deeply nested or highly aliased query can force exponentially more resolver calls and database round trips than the request's byte size suggests, so a rate limiter counting requests per second sees one request and misses the fact that it costs as much as ten thousand. The second is information disclosure through introspection: GraphQL's own reflection capability, `__schema` and `__type`, lets any client ask the server to describe every type, field, and mutation it exposes, turning a production endpoint into a self-documenting map of the entire data model for anyone who queries it.

Neither failure mode is a flaw in GraphQL as a technology — both are the direct, foreseeable consequence of moving query composition from the server to the client, and this lesson is about the controls that put a bound back on what the client is allowed to compose.

Analogy🏏Cricket

🏏 Think of it like cricket: A stadium's media-accreditation desk hands out passes with a fixed scope — a photographer's pass gets pitch-side access for the toss and boundary rope access during play, nothing more, because the desk decided in advance exactly which zones each pass type opens. Now imagine the desk instead issued a single generic pass that let the holder request access to any combination of zones they wanted at the gate, on the spot — the dressing room, the pitch during play, the broadcast booth, all in one visit, because nobody had pre-decided what a reasonable request looked like. During the 2023 World Cup final in Ahmedabad, accreditation was scoped tightly by role precisely because an unscoped pass system would let one credential holder demand access equivalent to ten separate specialist passes in a single walk-through, overwhelming security staff who budgeted for one photographer, not a photographer requesting the access footprint of a full broadcast crew. Just as the accreditation desk pre-decides the maximum zones a single pass can open, a GraphQL server has to pre-decide the maximum depth and cost a single query can request. Just as an unscoped pass lets one visitor's request cost as much as ten specialist visits, an unbounded GraphQL query lets one HTTP request cost as much as ten thousand resolver calls. The insight is that flexibility for the requester has to be paired with a hard ceiling set by the party paying the cost of fulfilling it, or the flexibility itself becomes the attack.