4 ms·

One concern I have with Graphql is security and access to data. I'm sure there are plenty of ways to control it, but I'd wager that most will be ignored outsid

One concern I have with Graphql is security and access to data. I'm sure there are plenty of ways to control it, but I'd wager that most will be ignored outside of basic ACL’s. Often times certain user types should only have access to certain fields in data or be able to query it in certain ways. Too often I see apps where the developers just assume they have full control since they're making the interface, while it's trivial to watch the API calls and intercept or modify them.

whalesalad 9y ago
This isn’t a GraphQL concern. The same issue happens with REST or any other communication strategy.
southpolesteve 9y ago
I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle: 1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here. 2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1] 3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option. At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e4df619827ae https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e... I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU https://youtu.be/vI9ERvz9WWU [1] https://gist.github.com/southpolesteve/e190e9572d060b515836666610b858a9 https://gist.github.com/southpolesteve/e190e9572d060b5158366...
oliwarner 9y ago
These other replies highlight what people are willing to overlook. REST APIs still control what they send. They don't have [to have] a complex parser. You can say they're "the same". GraphQL is an extra layer for developer-overlook (by design) and exploitation.
- oliwarner 9y ago
  *can't say

whalesalad 9y ago

This isn’t a GraphQL concern. The same issue happens with REST or any other communication strategy.

southpolesteve 9y ago

I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle: 1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here. 2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1] 3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option. At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e4df619827ae https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e... I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU https://youtu.be/vI9ERvz9WWU [1] https://gist.github.com/southpolesteve/e190e9572d060b515836666610b858a9 https://gist.github.com/southpolesteve/e190e9572d060b5158366...

oliwarner 9y ago

These other replies highlight what people are willing to overlook. REST APIs still control what they send. They don't have [to have] a complex parser. You can say they're "the same". GraphQL is an extra layer for developer-overlook (by design) and exploitation.

oliwarner 9y ago
*can't say