API tests

GraphQL API testing: permissions, errors and query complexity

GraphQL is a way to make data available between applications through an API. The client selects the fields it needs in the request and can also request related data. This flexibility reduces the number of separate calls, but introduces particular risks in permissions, error handling and performance.

What is the problem?

With GraphQL, simply repeating checks prepared for REST is not enough. GraphQL applications often expose a single endpoint that can be called with many combinations of fields and nested relationships.

If permissions are checked only on the main object, a nested query may unintentionally expose data that the user is not allowed to see. A very deep or highly branched query may, in turn, consume an unreasonable amount of resources. The user interface uses only a few prepared queries, so it may not reveal these situations.

What else to check

The fundamentals remain the same as for any API: correct responses, error states and boundary values. For GraphQL, we add the following:

• Different combinations of selected fields—not only a routine successful request, but also combinations used by mobile applications, partners or older client versions.
• Permissions across nested queries—ensuring that a relationship between objects cannot provide access to data for which the user lacks permission.
• Error behaviour—if an error occurs while a query is being executed, the response may contain HTTP status 200 and details in the errors field. We therefore check both the status code and the response body.
• Query complexity—limits on depth, complexity or the number of results so that a single query does not place a disproportionate load on the server.

How we address it

First, we list the operations, user roles and clients that call the API. We then prepare positive and negative scenarios in Python with pytest or in Playwright, and integrate them into CI/CD where appropriate. We also verify the authorisation matrix through nested relationships, while resource-intensive queries are assessed together with limits and performance measurements. If several clients rely on the API, contract testing can provide an additional layer.

What you gain

• A better view of which roles can access which data.
• Defects detected directly at the API layer, where their cause is generally easier to locate.
• Faster feedback in CI if you integrate the tests into the pipeline.

Next step

To find out whether your GraphQL tests cover permissions, field combinations and error states, start with a list of operations and user roles. The next step can be a no-obligation consultation in which we define an appropriate scope together.