When Client Developers Love GraphQL To Death

Photo by Stephen Radford on Unsplash

One day our devops director said to me, “Hey, I’m testing our AWS scale-out policies — can you make a GraphQL query that stresses the container?” So, knowing every intricacy and weakness of the API at that time, I did my worst.

My worst stressed that container, all right. Then it kicked the container in the groin and jumped up and down on it and rolled it off a cliff into a pool of lava (just came off a Minecraft break, okay?). This was on a staging environment, of course. I think.

So I figured out every hole in the API query-handling guardrails and fixed it. In this case, insider knowledge and adversarial intent was involved. But every other time, it was a client developer who did it by accident.

Here’s the problem:

GraphQL is awesome! It lets a client developer come up with their own API!

OMG, GraphQL lets a client developer come up with their own API… Against your back end.

All these problems can happen in a REST API too, and I’ve seen most of them. The difference is that REST server developers have to specifically enable them, whereas GraphQL sort of invites abuse.

Let’s take a simple GraphQL schema.

type Author {
  books: [Book!]!
  name: String!
}