All vulnerabilities
HIGHAppSecexploited in the wild

APPSEC-GRAPHQL-ABUSE

API · GraphQL API abuse (batching/aliasing/introspection)

Summary

GraphQL servers expose three abuse primitives stemming from the query language's flexibility. Leaving introspection enabled lets any client send a __schema query and recover the entire type system, including internal admin mutations and deprecated fields, providing a map of the attack surface (OWASP API8/API2). Because per-request rate limiters count one HTTP request regardless of operations inside it, an attacker can use field aliasing (e.g. attempt0:login(...), attempt1:login(...)) or array batching to pack dozens of login or verifyOtp mutations into a single request, brute-forcing credentials or short OTP/2FA codes while the rate limiter sees only one request; this aliasing-bypass technique is reproduced in the PortSwigger Web Security Academy 'Bypassing GraphQL brute force protections' lab and Wallarm's GraphQL batching research. Deeply nested or recursive queries cause an exponential explosion of resolver and database calls, exhausting CPU, memory and connection pools for denial of service, the core of OWASP API4:2023 Unrestricted Resource Consumption. HackerOne has disclosed a real GraphQL authentication-bypass finding, and Apollo Server v4 disabled array batching by default in response to these attacks.

How to avoid it in your code

  • Disable introspection and field suggestions in production GraphQL endpoints.
  • Enforce query depth, complexity and node-count limits before resolver execution.
  • Rate-limit per operation and per alias, not per HTTP request; cap batch size.
  • Reject or restrict array batching; set Apollo batching to disabled.
  • Apply OTP/login throttling at the resolver, counting every aliased mutation.

References

Related vulnerabilities

All AppSec →