GraphQL API Security Best Practices: A Curated List

I framed this list around the controls that appear repeatedly in current GraphQL security guidance from graphql.org, OWASP, and practitioner checklists such as safeguard.sh, and I picked each for a distinct failure mode rather than blanket coverage. Some options, like persisted queries, only work when you control the client code and build pipeline; others, like rate limiting or authorization guards, apply whether you serve an internal tool or a public developer platform.

Persisted queries / trusted documents

Persisted queries build an allowlist of GraphQL operations by hashing approved documents during the build and letting clients send only the hash at runtime. This is strong because it removes arbitrary query submission from first-party apps, which is the main vector for complex denial-of-service. Skip it if you run a public API where third-party developers write their own operations, since those queries cannot be known in advance.

Depth and complexity limits

Depth limits reject queries nested beyond a configured threshold, while complexity analysis assigns a per-field cost score so a shallow query cannot still request thousands of expensive items. Together they catch recursive relationship attacks — posts whose authors have posts whose authors have posts — and oversized pages like first: 1000000. Depth-only setups miss wide-but-shallow queries, so add complexity scoring if your schema is heavy on list fields.

Introspection gating

Introspection exposes the full schema in a single query, which is useful in development but lowers the cost of reconnaissance in production. Current guidance treats disabling it in production as defense-in-depth, not access control, because a determined attacker can still probe field names. Use it for public external APIs, but pair it with authorization and rate controls rather than relying on it alone.

Object-level and field-level authorization

Because GraphQL routes everything through one endpoint, authorization cannot sit at the route layer; it must be enforced in the resolver closest to the data. Field-level guards protect sensitive fields — for example, a User.email that the caller should not see — while object-level checks prevent broken object-level authorization holes like user(id: $id) returning any user. This is essential for any API that exposes data differently depending on the caller.

Cost-based rate limiting and batching controls

GraphQL batching and aliasing let a single request invoke the same expensive field many times, multiplying work and bypassing naive request-count limits. Cost-based rate limiting counts operations or query cost instead of HTTP requests, and capping batched operations plus aliases limits amplification. This matters for public or high-traffic APIs where per-request limits provide little protection.

Authentication context and directive-based authorization

Extract a JWT or session token on every request and attach the user to the GraphQL context; directives then keep authorization logic declarative and visible in the schema. This keeps validation close to the request boundary and makes policy easy to audit. Public APIs should still combine it with cost controls, because authentication alone does not stop expensive operations.