how to secure GraphQL endpoints

TL;DR

GraphQL's flexibility is the risk: one endpoint can ask for anything, so you have to bound what it can ask for. Disable introspection in production, cap query depth and complexity, require persisted queries for your own clients, and enforce authorization at the field level. A small query triggering huge nested joins is the attack to design against.

The query

how to secure GraphQL endpoints

Use this when

• You are shipping a new GraphQL API
• A review flagged introspection exposure or missing depth limits
• You are auditing an existing endpoint for abuse potential
• Your own clients are the main consumers and you can lock down ad-hoc queries

Not for

• REST API security
• GraphQL schema design
• Client-side caching
• Database tuning

Steps

1. Disable introspection and the playground in production

Introspection hands attackers your full schema. Turn it off outside development, along with GraphiQL or any playground UI.

Expected output: an introspection query returns an error in production but still works in dev.

2. Set a max query depth

Reject queries nested deeper than a sane limit, usually 10 to 15 levels. This kills the classic deeply-nested alias attack.

Expected output: a query nested 50 levels deep is rejected with a clear error.

3. Add query complexity analysis

Assign a cost to each field and reject queries over a total budget. Depth limits alone dont stop a shallow-but-wide query from fanning out into thousands of resolver calls.

Expected output: a query asking for 10,000 nested records in one shot is rejected for exceeding complexity.

4. Use persisted queries for your own clients

Register the operations your app actually uses (by hash) and only execute those. Ad-hoc queries from anyone else get rejected. This turns the API surface from infinite to a known list.

Expected output: your app works unchanged; arbitrary queries from curl are rejected.

5. Rate limit by query cost, not just request count

One expensive query can cost more than a thousand cheap ones. Feed the complexity score from step 3 into the rate limiter.

Expected output: a client hammering expensive queries gets throttled while normal use is unaffected.

6. Enforce authorization at the field and resolver level

Checking auth only at the query root leaves nested fields exposed. Every resolver that returns sensitive data checks permissions itself.

Expected output: requesting another user's private fields returns an authorization error even when the query shape is valid.

7. Sanitize errors in production

No stack traces, no internal type names, no database errors in responses. Log the details server-side; send the client a generic message.

Expected output: a failing query returns a clean error with no internals.

8. Set timeouts

Cap how long a single query can run so one expensive request cant hang a worker.

Expected output: runaway queries die at the timeout instead of piling up.

Variant phrasings

GraphQL introspection exposure fix

Step 1. If you need introspection for developer tooling, gate it behind authentication instead of leaving it public.

GraphQL query depth limit

Steps 2 and 3 together. Depth alone is not enough; add complexity.

GraphQL denial of service prevention

Steps 3, 5, and 8 are the DoS story: bound the work, price the work, time-box the work.

Why it happens

REST exposes fixed endpoints with fixed costs; GraphQL exposes a query language where the client composes the cost. Developers ship it like REST, with auth at the door and no limits inside, and the endpoint happily executes whatever nested monster a client sends. Every control on this list exists because the server has to bound work the client gets to define.

Edge cases

• Public APIs that need introspection for developer experience: gate it behind auth or a separate developer endpoint.
• Subscriptions: they bypass per-request rate limits by design. Apply the same complexity checks and add per-connection limits.
• Persisted queries and third-party integrators: give partners their own registered operation list rather than reopening ad-hoc queries.
• Complexity scoring for custom scalars and federation: score the most expensive resolver path, not the average; federated subgraphs each need the limits, not just the gateway.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVJmtoP00gvaceU6YUVf5Q