The difference is the graphql schema creates valid sql in a prepared statement, it just might not be what you would normally allow the user to retrieve.
But yes, validation of user input is key. GraphQL needs some better tooling support around that.
It depends on the implementation. I've once used GraphQL in a pet project and you could only pass some generic values (e.g. ids) and then select fields you want, for example:
query{user(id:1){loginnameposts{idtitle}}}
id there would be passed to an ORM (Users.get(by: id).with(model: Post)) and I'd simply return this data to my GraphQL level which then would fetch everything user requested (so if my User model has id, email, etc., a GraphQL library would only take login and name from it and posts would return an array of posts that would be handled the same way) and return it to them. I've fetched everything I needed in one query compared to 2 REST calls (/api/users/1, /api/users/1/posts) and it's pretty safe as long as you prepare the id value under the hood. I doubt anyone uses GraphQL just like a SQL generator. It's not safer than exposing a raw SQL endpoint like /api/sql/$whatever_sql_you_can_come_up_with?variable=;drop everything; --lul.
Of course there are downsides such as complexity and attribute accessibility by roles, though I've implemented that by dynamic attributes that would return an error/null if you don't have permission to read this attribute. And the complexity problem was solved by the library itself - I simply put a limit on the depth of the query, so you can't do something like query { users { posts { user { posts { user ... } } } }
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The difference is the graphql schema creates valid sql in a prepared statement, it just might not be what you would normally allow the user to retrieve.
But yes, validation of user input is key. GraphQL needs some better tooling support around that.
It depends on the implementation. I've once used GraphQL in a pet project and you could only pass some generic values (e.g. ids) and then select fields you want, for example:
id
there would be passed to an ORM (Users.get(by: id).with(model: Post)
) and I'd simply return this data to my GraphQL level which then would fetch everything user requested (so if my User model has id, email, etc., a GraphQL library would only takelogin
andname
from it andposts
would return an array of posts that would be handled the same way) and return it to them. I've fetched everything I needed in one query compared to 2 REST calls (/api/users/1
,/api/users/1/posts
) and it's pretty safe as long as you prepare theid
value under the hood. I doubt anyone uses GraphQL just like a SQL generator. It's not safer than exposing a raw SQL endpoint like/api/sql/$whatever_sql_you_can_come_up_with?variable=;drop everything; --lul
.Of course there are downsides such as complexity and attribute accessibility by roles, though I've implemented that by dynamic attributes that would return an error/
null
if you don't have permission to read this attribute. And the complexity problem was solved by the library itself - I simply put a limit on the depth of the query, so you can't do something likequery { users { posts { user { posts { user ... } } } }