GraphQL is a hot smoking pile of garbage
aista.com
aista.com
> "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."
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!"
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 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.
Your 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.
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.
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.
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.
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'.
My advice to the author is delete this immediately and go learn graphql.