Back to Field Notes
API & Application Security/Field Note

GraphQL Security — The Issues That Surface After Production

Query depth and complexity, batch attacks, introspection in prod — GraphQL's flexibility is its security challenge.

Author

Marco Pereira

Principal Application Security Engineer

Published

February 16, 2026

Read

9 min

Share
AI-generated illustration of a banking data center
AI-generated illustration of a banking data center
Key Takeaways
  • 01Recurring GraphQL issues: unbounded query depth/complexity (resource exhaustion), batch and alias attacks (rate-limit bypass), introspection in prod (schema enumeration), field-level authorization gaps (BOPLA at scale), persisted-query-not-enforced (arbitrary execution).
  • 02Defenses that survive contact with real APIs: gateway-enforced depth/complexity limits, persisted-query allowlist for production clients, introspection disabled in production, field-level authz in resolvers (not at the route), per-operation (not per-request) rate limits.
  • 03Persisted queries — client sends an ID, server resolves to a pre-registered query — eliminate most attack classes. Friction is on the developer-experience side; the win is significant. Adopt for any GraphQL API serving high-trust clients.
  • 04Batch and alias attacks let an attacker send N operations in one HTTP request. Per-request rate limits do not stop them; per-operation cost accounting at the gateway does.

GraphQL is a powerful API style that consistently surfaces a specific cluster of security issues. Most are predictable; many are still un-mitigated in production deployments.

The recurring issues

  • 01Unbounded query depth and complexity → resource exhaustion
  • 02Batch and alias attacks → bypassing rate limits
  • 03Introspection enabled in production → schema enumeration
  • 04Field-level authorization gaps → BOPLA at scale
  • 05Persisted queries not enforced → arbitrary query execution

Defenses that survive contact with real APIs

Query depth and complexity limits enforced at the gateway. Persisted queries with a closed allowlist for production clients. Introspection disabled in production. Field-level authorization implemented in resolvers, not at the route. Per-operation rate limits, not per-request.

Persisted queries done right

Persisted queries — the client sends a query ID, the server resolves to a pre-registered query — eliminate most class of attacks. The friction is on the developer experience side; the win is significant. Adopt persisted queries for any GraphQL API serving high-trust client applications.

#GraphQL#API Security#Performance

/WRITTEN_BY

Marco Pereira

Principal Application Security Engineer · Alexa Cybersecurity