GraphQL Security

Beyond normal web security

GraphQL APIs face the usual web risks (injection in resolvers, broken authentication) plus some specific ones: broken object-level authorisation across nested paths, denial of service through expensive or deeply nested queries, alias and batch abuse to bypass rate limits, verbose error messages, and schema exposure through introspection on public endpoints. Controls: authorise in the data layer, depth and cost limits, timeouts, rate limits by cost, masked errors, disabled or restricted introspection, and persisted queries for first-party clients.

Secure, evolvable, scalable

Security controls, schema evolution and federation keep a GraphQL API healthy over time.

A security review list for GraphQL

Questions per API.

- Is every object authorised where it is loaded, regardless of query path?
- Are depth, cost, page size and timeout limits enforced?
- Are aliases and batched operations counted in rate limits?
- Are unexpected errors masked (no stack traces, no SQL in messages)?
- Is introspection disabled or restricted on public production endpoints?
- Are resolver inputs validated and passed safely to databases and services?
- Are subscriptions authenticated at connect time and authorised per event?

Test with hostile queries

Add tests that send deep, aliased and oversized queries to confirm limits actually reject them.

Quick check: Which risk is particularly associated with GraphQL?

• Inability to authenticate
• Missing TLS by design
• Lack of a type system
• Denial of service through deeply nested or very expensive queries