• It is a query language
  • better than REST since it loads only necessary fields from the server

It avoids returning all the fields in a JSON response, you can pick out only the required fields for your application

By doing this we can save time on parsing the JSON body returned from the API call and only reading the fields that we need. Saves bandwidth as well by pulling only the required data

  • Check if the graphQL endpoint has introspection enabled in the production

Disable introspection in the configuration

  • Authorization based flaws : run queries to exfiltrate the data that is not visible on the UI
  • Check if suggestions are enabled, certain frameworks allow suggestions when you type a invalid field that matches closely to a valid field on the remote server

example: There is no entry for ‘productInfo’. Did you mean ‘productInformation’ instead?

You can disable suggestions to mitigate this attack

  • Instead of traditional bruteforce, you can use alias in graphql to repeatedly call the same function multiple times in a single HTTP request. It is not possible for a WAF to block this attempt

you can configure the operation limit; which will restrict the server to maximum number of unique fields and aliases in a query to prevent this attack

Also limit the depth of the query that can be ran

  • Check if the application checks for the content-type header in the request, if it allows the x-www-form-urlencoded you can replicate the request using form tag allowing CSRF in graphql based applications

implement a CSRF token that needs to be validated in the server-side

References

  1. https://github.com/doyensec/inql - GraphQL testing addon for Burpsuite
  2. https://github.com/nikitastupin/clairvoyance - A tool to automatically recover all the schema from sugesstions
  3. https://portswigger.net/web-security/graphql