Infinite loop query

Hi all,

This might seem like a dumb question to someone more educated on Graph, but I’m still curious.
What prevents a malicious user from submitting a non-halting GraphQL query to the network? What would happen to the network if an infinitely looping query were submitted?

1 Like

Great question. Due to the relative “openness” of graphql endpoints due to the nature of how it works (declare possibilities through the schema, allow arbitrary queries [unless of course you decide to limit access to your endpoint or use “persisted queries”]) DDoS attacks are definitely a concern. Even more than for traditional APIs because the possible query “vectors” are pretty much endless compared to the finite number of query arguments that a traditional REST API would offer.

There are a number of ways for how one can solve this problem though. The most drastic, as I already mentioned, would be to a) restrict access to the api or b) only expose a number of pre-defined queries, so-called “persisted queries” that are generated (or manually created) depending on your app’s data requirements (e.g. through a build step that gathers all graphql queries that your app is going to send).

Now, since we are talking about an open api in this case and there’s also no support for persisted queries through graph-node (because it’s an open api and not limited to one particular app), let’s look at how this is solved in case of graph-node:

All queries sent to the graphql endpoint are validated for correctness (syntactically correct and within the boundaries of the schema) but also for …:

a) Max Depth
b) Max Complexity

Max Depth:
The max depth validation limits the number of subselections you can perform in a graphql query. E.g. a deeply nested query like this would not be allowed:

query cyclical {
  author(id: "xyz") {
    posts {
      author {
        posts {
          author {
            posts {
              author {
                ... {
                  ... # more deep nesting!
                }
              }
            }
          }
        }
      }
    }
  }
}

Max Complexity:
In addition to only checking the depth, the max complexity validation step ensures that a query that’s overly complex (e.g. a lot of fields + lists/arrays with a lot of records & nesting) does not exceed a certain “complexity score threshold”.

Code reference: graph-node/query.rs at 98314177e258d50eebbd87e40f50d46e4530adbe · graphprotocol/graph-node · GitHub

Further explanation: https://leapgraph.com/graphql-api-security

3 Likes

Is this problem with our subgraph or with the graph system?

If is problem with our subgraph how can we fix it?

/cc @Oliver can you please help me with this?