When Client Developers Love GraphQL To Death
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!
}