As a GraphQL API gives you a lot of extra power and possibilities, it also introduces some new attack vectors. Nothing prevents the user of your (web) application to open the developer console and start creating and sending other queries to your GraphQL backend. By using the authentication token already available, he/she can call your API. So without further mitigations a user can create and run any query he/she can think of.
Luckily there are multiple ways to control this attack vector. In a first post I introduced the concept of a complexity budget. Today we have a look at query depth.
What is query depth?
The depth is the number of nesting levels of the query. The following query has a depth of 3:
By setting a query depth, you can protect yourself against cycles in your graph leading to infinite recursive queries:
How to limit the query depth?
To limit the query depth, we need to update our GraphQL server configuration and set a MaxExecutionDepthRule: