Alexa Cybersecurity
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
Stock photograph of server racks
Stock photograph of server racks
Contents (3)
  1. 01The recurring issues
  2. 02Defenses that survive contact with real APIs
  3. 03Persisted queries done right
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