[RFC] Crytographically Signed GraphQL queries

[MarcusWalz00]

When two objects are interrelated (e.g. a type Car with a many-to-many relationship to type Manufacture), it's possible for things to get out of control and make graphql api's especially vulnerable to denial of service attacks, e.g. consider the following query:

query {
  cars {
    make {
      cars {
        make {
          cars {
           name
            year
          }
        }
      }
    }
  }
}

One solution has been to set a maximum query depth. However this approach is not a silver bullet as many appropriate queries might be rather deep and some rather shallow queries can create chaos.

I propose an alternative solution where graphql queries are cryptographically signed when an authorized client of a graphql api is compiled using some kind of hash function. The client sends the query hash to the server and the server verifies the hash matches the query:

{
  query: "..."
  variables: {},
  signature: "abcd-123-456"
}

• Publicly distributed grahpql clients should compute signature at build time the downside here is queries must be static, dynamic queries are probably not compatible with signed queries.
• Trusted clients or users of an api could dynamically sign their queries or bypass signing altogether via authentication.

Signed queries shouldn't be considered a means to secure an API, but rather as a way to mitigate the risks of a DDoS attach on publicly exposed GraphQL endpoint.

Because signed queries require coordination between client and server I believe it should be incorporated into the grahpql spec.

This seems so simple, so apologies if it's already been considered. I couldn't find anything on the topic.

[benjie]

This is very similar to an approach called “persisted queries” or “stored/persisted operations” (not to be confused with “automatic persisted queries” which serve a slightly different purpose). One notable difference between your approach and that of persisted operations is with persisted operations you only need to send the hash and the document can be hydrated from that; this has an added advantage that the request size is reduced, however it has the drawback that every query must be supplied to the server in advance (e.g. at client build time).

In my opinion this is more of a transport concern than something that needs integrating into the GraphQL spec itself; you should check out the GraphQL-over-HTTP specification, and in particular graphql/graphql-over-http#38

[sungam3r]

Agree with @benjie .