The flexibility that's also the risk
REST APIs expose fixed endpoints, each with a roughly predictable, bounded cost. GraphQL's core design advantage — letting a client specify exactly the shape and depth of data it wants in a single request — is also precisely what creates a resource-exhaustion risk that REST doesn't share in the same way: a single, perfectly valid query can request deeply nested, multiplicatively expanding data in one round trip.
How the multiplication actually works
Consider a query fetching 100 users, each with 50 posts, each with 50 comments, each comment's author fetching another 50 posts. The resolver work required isn't additive — it's multiplicative: 100 × 50 × 50 × 50, easily reaching into the hundreds of thousands or millions of resolved objects from what looks, on the page, like a modestly sized query with a handful of nested fields.
Why this specifically matters for security, not just performance
Because this cost scales multiplicatively with nesting depth and pagination arguments rather than with the visible size of the query text, an attacker (or simply a careless client) can craft a small, innocuous-looking query that forces a disproportionate amount of database and server work — a denial-of-service vector that's specific to GraphQL's query model and easy to overlook if a server doesn't explicitly guard against it.
What actually needs to be measured
- Maximum nesting depth. Each additional level of nested selection sets compounds potential cost — most production GraphQL servers cap this somewhere around 5 to 10 levels.
- Pagination argument fan-out. Multiplying together the
first,limit, orlastarguments found at each nesting level gives a concrete, calculable estimate of worst-case total resolved objects — a real number, not just a subjective sense that "this looks deep."
The standard mitigations, and why all three matter together
Depth limiting alone (rejecting queries beyond a fixed nesting level) doesn't catch a shallow-but-wide query with enormous pagination arguments at just two or three levels. Query cost analysis — assigning an explicit cost to each field or connection and rejecting queries exceeding a budget — catches what pure depth limiting misses, and server-side pagination caps ensure a client's requested first or limit value can never exceed a safe maximum regardless of what's specified in the query itself.
Why this is worth calculating before, not after, an incident
A query complexity problem typically surfaces in production as an unexplained server load spike or timeout under otherwise normal traffic — tracing that back to a specific query pattern after the fact is considerably more work than calculating expected worst-case complexity for new query patterns as they're added to a schema, and setting appropriate limits proactively.
Frequently Asked Questions
REST APIs expose fixed endpoints with roughly predictable, bounded cost. GraphQL's core flexibility — letting a client specify the exact shape and depth of nested data it wants in one request — means a single, perfectly valid query can request deeply nested, multiplicatively expanding data that REST's endpoint structure simply doesn't allow in the same way.
Cost multiplies rather than adds across nesting levels — 100 users, each with 50 posts, each with 50 comments, is 100 × 50 × 50 (250,000) resolved objects, not 100 + 50 + 50. A query with just a few more nested levels or larger pagination arguments at each level can reach into the millions from what looks like a modest amount of query text.
Not by itself. Depth limiting catches deeply nested queries but misses a shallow-but-wide query with enormous pagination arguments (first: 10000, for example) at just two or three levels. Query cost analysis and server-side pagination caps are needed alongside depth limiting to close that gap.
By multiplying together every first, limit, or last pagination argument found at each nesting level in the query — a concrete, calculable estimate of the worst-case total number of objects the query could force the server to resolve, rather than a subjective sense of how deep or complex a query looks.
Yes — the GraphQL Query Complexity Analyzer genuinely parses a pasted query's brace nesting structure to calculate real depth, and multiplies detected pagination arguments to estimate worst-case node fan-out, flagging queries likely to exceed common production server limits.