Security risks with GraphQL

An API exposes valuable data to be used by programs. REST is a standardized client-server architecture for APIs where resources are available at specific URLs. The client can query them (GET) and even write, modify and delete entries when specific endpoints exist.

GraphQL is a new approach. In most configurations, you will use one endpoint only to combine multiple queries in a single request.

It has many advantages over REST that can make sense, but it might raise security issues as well:

  • the default /graphql endpoint URL is quite often used in production, so it is an easy target
  • the introspection feature is sometimes left enabled on production, which can lead to non-public information disclosure
  • self-inflicted DDOS (distributed denial-of-service) are not uncommon because GraphQL queries can be significantly larger than REST queries (e.g., 10000 users and 70 posts per user makes 700 000 nodes to retrieve)
  • GraphQL schema design can be quite challenging, leading to expose more information than intended
  • string injections are not uncommon as queries are usually wrapped in JSON
  • everything connects to everything else, sometimes leading to authorization bypass when checks are not performed for each node

However, there are measures you can take:

  • don’t use the default endpoint /graphql
  • force SSL everywhere
  • use standardized authentication such as JWTs or OAuth
  • limit GraphQL operations to authenticated requests, as you’re not a public platform such as GitHub
  • limit query depth and add pagination
  • use static queries and avoid dynamically generated queries at runtime when it’s possible
  • disable logging, debugging and exploration tools on production (including GraphiQL), not only for security reasons but also for performance

Read the OWASP cheat sheet for more details.