Define maximum query depth for graphQL?

[fredro84]

Recently I have been migrating all of my graphql queries from a custom postgraphile api to the supabase graphql api. During the migration I was investigating which safety measures I can implement against large (accidental) queries. I found that the max number of rows returned is 30 and totalCount is disabled by default. But I can't find whether I can configure the maximum query depth for a graphql query. This means 30 rows for each level of the query, but if that query can go 20 levels deep, the response will be huge.

I found the default timeout settings for users: 3 sec (anon), 8 sec (authenticated). But for an authenticated user they can probably use up quite some resources in 8 seconds if I don't limit the query depth.

Does anyone know what a good approach is here?

[sand97]

Hi @fredro84 any update ?

[fredro84]

@sand97 defining query depth is still not possible and I find the solution a little too risky what @steve-chavez proposes below. So I'm slowly migrating away from graphql all together. Supabase doesn't supply the required security measures at the moment. Because rate limiting still hasn't been developed, this means that any (authenticated) user could still send multiple heavy queries that would put heavy strain on my database, even if I have set up the cost_limit for one request.

What I have decided to do instead is create custom SQL functions that return a fixed set of data, and I limit the amount of results that are returned specifically per function. I call these functions with the supabase rpc method. It is less flexible than graphql, but I see no other option to build something secure enough for now. A bit disappointed though, because I was a big fan of graphQL, especially with a PostGraphile setup.

But don't get me wrong, I still think Supabase is by far the best value for money!

[steve-chavez]

You can use the pg_plan_filter module to limit the query cost, this is included in Supabase. For example, you could do:

ALTER ROLE authenticated SET plan_filter.statement_cost_limit = 100000.0;