GraphQL a security disaster waiting to unfold

Hi Thomas, GraphQL schemas for a service are specified using what's known as the GraphQL SDL (Schema Definition Language), Schema-First methodology is also the most common thingy in this context.

GraphQL has 3 categories of operations, i'm adding them with the http equivalent to showcase:

• Query (GET)
• Mutation (POST, PATCH, PUT, DELETE)
• Subscription (Websockets, SSE)

In each type of request that you want to handle, there are different parts. A definition on what it contains and a definition on what it returns.

The operations are performed through Resolvers, see example below:

const resolvers = {
    Query: {
        getAllUsers() {
            // do whatever you like
            return users;
        },
        getUser(parent, args) {
            // do whatever you like, example:
            const user = users.find(u => u.id === parseInt(args.id));
            if (!user) throw new UserInputError(`The user ${args.id} was not found`);
            return user;
        }
    },
    Mutation: {
        createUser(parent, args) {
        // do whatever you like
       ...

It's up to you how to resolve each request. It's usually one of two things:

Request -> Resolver -> Req Validation -> ORM
or
Request -> Resolver -> Endpoint (which can be a REST req and this endpoint will also implement a Req Validation and a call to an ORM)

Of course the ORM is optional but as it's the most common I'm sticking with this flow.

Please note that GraphQL itself it's just a definition (which is the model you want to expose, how you are going to resolve the requests and what will you return as response) thus it has nothing to do with security alone.

The security, as well as you do on a regular http endpoint, is up to you. The framework, libs, handlers and functions need to be arranged in a way that prevent security vulnerabilities. Usually the framework and the ORM have standard functions/methods to deal with common security concerns, you can use dedicated libs for each topic if you prefer so.

GraphQL is not "an easy alternative to HTTP", it has it's pros and cons (yet most of them have been tackled by now) like any other tech and yes, both have a common point in utility (resolve requests through TCP/UDP, multiplexed or not). Depending on what you need to build it will be easier or harder, more or less convenient or a better or worse choice using a tech or another.

I don't want to convert this comment in an entire post explaining what GraphQL is and how it works, what architectures are suitable for it, what it does and what it don't and going to the detail but I assume that with the information yet provided it should suffice to showcase.

When the client is constructing the queries, it's (almost) impossible to prevent it from constructing malicious queries. The client is "user land", implying anybody with a Postman account can create queries. Even if you get all authorisation objects correctly applied towards the different tables you've got, you're still left with problems such as those originating from batch queries, where your GraphQL server ends up "DOS attacking" your database, creating a "query storm", plus a bajillion additional problems.

There are ways to secure GraphQL, by for instance not allowing the client to create queries, but rather constructing the queries in your middleware, and exposing statically types endpoints to the client. The problem is that most aren't using GraphQL this way, they see GraphQL and start thinking; "Cool, 'server less'", and implements all business logic on the client, allowing for creating queries in "client land".

The second problem is that even if you're able to somehow completely secure GQL, you're still ending up with a solution that for all practical concerns moves all business logic into client space. Typically the same API have multiple clients. You're now risking that each client implements its business logic differently, and/or users bypassing your business logic with their Postman accounts, resulting in "bad data".

The problem with using GraphQL this way is that it reduces your middleware to a "fancy database thing". It hence solves nothing really, but only "moves" the problem to an outer layer.

Most people commenting here claims they're not using GraphQL this way, as in exposing the query building directly to the client. This is probably true. However, most people commenting here aren't representative of how GraphQL is used by most developers.

However, it's the idea of GraphQL that's the problem, because if you give people a big shotgun, most people are going to shoot themselves in their legs. As a library developer I've learned one thing, which is to restrict usage of a library as much as possible. Even though I can perfectly apply the library, most others cannot, and will abuse it in ways it wasn't intended to be used ...

The above screenshot has a GraphQL vendor in the parts which are censored. This implies that the only thing that's between the database and the frontend client is a GraphQL server. This is the only product this particular vendor happens to have, and we must hence assume 98% of its clients are using GraphQL like this. To further emphasise that, realise that this particular vendor is using this as their "best practice use case" in their marketing. This particular vendor has 35,000+ stars on GitHub. There's another similar vendor with 70,000+ stars on GitHub, delivering the exact same product ...

The architectural sketch above is a use case from a FinTech provider. This company have 3,500 users. One of them might be you. If they're PCI compliant, they've got your credit card information. I consider this a really big deal ... ;)

Here's the first paragraph from GraphQL's primary website. They're basically summing up the problem a hundred times better than I can do myself.

If you use GraphQL like GraphQL's website tells you to do, you're in a "security disaster land", because everyone with a Postman account can construct Graph queries you hadn't anticipated ...

It's basically one step up from allowing the client to pass in raw SQL queries ...

Disappointing because I was hoping for an unbiased argument

You could try to argue factually instead of doing an ad hominem ...?

Just sayin' ... :/

It would certainly increase your credibility ...

I would at least ensure we had something to actually discuss at least ... ^_^