> You also don't have to (and I'd say you shouldn't) map your SQL database to your GraphQL schema 1 to 1.
My main complaint about GraphQL is that junior engineers tend to use it as an excuse to do exactly that. They don't understand that the API and database schema are different things.
How is that a complaint about GraphQL when the common alternative, REST, was basically designed to map 1:1 API resources to database tables. Each endpoint is a resource, and every resource is almost always either most of a table or a simple table join.
GraphQL is a great way for letting apps and people query data in _the way you intended it to be queried_.
SQL injection is about querying and change data in ways _that were not intended_.
This article is comparing apples to oranges. If you're using this articles logic, any kind of dynamic queries are SQL INJECTION.
The article also assumes that GraphQL = no security, which is not a general assumption you can make, and, which you could also apply to any other technology.
I have been working daily with GraphQL for 6 years and have no idea what the author is talking about. And I cannot find a single thing sustaining his claim in the article.
There are difficulties with GraphQL such as limiting n+1 requests while also having complex db level permissions. But I really don’t see how sql injections would happen more often than with classic rest.
This is one of the most laughable critiques I've read.
> "First of all, GraphQL is almost the equivalent of allowing the frontend client to send SQL to the database. For crying out loud, we’ve got a name for that, and it’s called SQL INJECTION ATTACKS."
GraphQL is a specification, it doesn't imply an implementation.
A GraphQL "resolver" is identical to the concept of an "endpoint", you have no idea what the business logic inside of an endpoint is. That's up to the implementer.
> "I know it is possible to apply security to your GraphQL endpoints, by amputating half of its features. However, security is one of those things you need by default. If some piece of tech doesn’t have “security by default”, you don’t expose it to anybody not having root access to your server infrastructure, period!"
No API specification I am aware of comes with "security by default", again, that's an implementation detail?
It's to you to add AuthZ/AuthN to your REST/RPC/GQL etc API, by themselves the handlers are just dumb networked functions.
> "Second of all, GraphQL forces you to write business logic on the client. This implies that everyone with a Postman account can circumvent your business logic, and potentially empty your bank account, and transfer your entire holdings to their own account, in Bermuda, while publicly sharing images on Instagram that they’re drinking umbrella drinks from their hammocks on the beach."
I really don't have anything to say on this.
I guess the implication is that you have somehow exposed your entire database with zero access controls via GraphQL and don't know how to write resolvers?
In that case, I'm more concerned for your employer than your angst against GQL, lol.
no strong opinion either way here, but would have liked to see a bit more technical depth here beyond the allegations of sql injection and a click baity title.
1. graphql absolutely does not open you up to sql injection attacks. You could certainly end up being trapped by a endless recursive call loop but there are ways to clip your tree to avoid that!
2. graphql does not force your business logic to the client. you write a mutation. it takes parameters. whatever goes on after that is in the server and is whatever you want ON THE SERVER.
disclaimer: I built my startup on graphql.
Their hyperlambda product seems interesting but the number of things they get flat out wrong about sql makes me question if they did their homework before trying to make something better.
This is hilarious; I don't think I've ever encountered trolling that goes this deep. Beyond this GraphQL post, the other blog articles are even funnier -- and then there's the github repo and its fake issues.... brilliant!
I was kind of excited when I saw the headline, because I am currently going through a bit of graphql fatigue. But, wow, this is a majorly misinformed person. I generally love the clickbait style, but you cannot be entirely clueless or it just becomes obvious the dunning kruger effect is at play which is whats happening here.
My advice to the author is delete this immediately and go learn graphql.
22 comments
[ 3.3 ms ] story [ 58.2 ms ] threadYour typical "POST Body" in GraphQL is strong typed the same way as the response body.
You also don't have to (and I'd say you shouldn't) map your SQL database to your GraphQL schema 1 to 1.
In my experience, databases like Firebase are more likely to be susceptible to these attacks given their hard to understand permission models.
My main complaint about GraphQL is that junior engineers tend to use it as an excuse to do exactly that. They don't understand that the API and database schema are different things.
SQL injection is about querying and change data in ways _that were not intended_.
This article is comparing apples to oranges. If you're using this articles logic, any kind of dynamic queries are SQL INJECTION.
The article also assumes that GraphQL = no security, which is not a general assumption you can make, and, which you could also apply to any other technology.
There are difficulties with GraphQL such as limiting n+1 requests while also having complex db level permissions. But I really don’t see how sql injections would happen more often than with classic rest.
A GraphQL "resolver" is identical to the concept of an "endpoint", you have no idea what the business logic inside of an endpoint is. That's up to the implementer.
No API specification I am aware of comes with "security by default", again, that's an implementation detail?It's to you to add AuthZ/AuthN to your REST/RPC/GQL etc API, by themselves the handlers are just dumb networked functions.
I really don't have anything to say on this.I guess the implication is that you have somehow exposed your entire database with zero access controls via GraphQL and don't know how to write resolvers?
In that case, I'm more concerned for your employer than your angst against GQL, lol.
Even if you have traditional REST endpoints, you still have to potentially orchestrate their usage client-side.
2. graphql does not force your business logic to the client. you write a mutation. it takes parameters. whatever goes on after that is in the server and is whatever you want ON THE SERVER.
disclaimer: I built my startup on graphql.
Their hyperlambda product seems interesting but the number of things they get flat out wrong about sql makes me question if they did their homework before trying to make something better.
My advice to the author is delete this immediately and go learn graphql.
Yes. I may very well have goals that imply pulling some data and doing client-side work that is inappropiate for upstream.
Picking where/when to do work is sometimes referred to as 'engineering'.