The contents of the GraphQL working draft[0] do not include any of the following...

TheAceOfHearts · on Feb 16, 2016

GraphQL itself has no position on any of those things, it's out of scope and up to the developer to handle.

You can return null if someone requests an object they're not allowed to access, or return an error, or whatever it is that you're currently doing.

I've been playing around with GraphQL, and my approach has just been to include a permissions object for the actions a user can take on the resource:

  { permissions: { destroy: false, update: true, ... } }

You SHOULD be checking permissions on each node and edge, but the details are entirely in your hands.

dsp1234 · on Feb 16, 2016

You SHOULD be checking permissions on each node and edge, but the details are entirely in your hands.

I agree 100%.

However, that's not what the GP said above, which was "It is a view model abstraction on top of your database which includes permissions checks for each node and edge, so in many ways it's actually more secure than the alternative of securing each endpoint adhoc.". I contest the use of "includes permissions checks" and "actually more secure" for a system that does not at any point specify any type of security at all. It's just as secure as any random REST API or route (in other words, as secure as you make it, and not any more).

carsongross · on Feb 15, 2016

See below: I think Peter Hunt is talking about Facebook's internal (or maybe public?) server-side implementation of GraphQL. That's the only way his comments make any sense given what's publicly available.

dsp1234 · on Feb 15, 2016

That's certainly possible, but it cuts against his argument which is that "It is a view model abstraction on top of your database which includes permissions checks for each node and edge".

That's maybe what FB's internal vision of GraphQL is, but that's not what we have available out here in non-FB land. If carsongross's argument is that GraphQL is moving the database to the client side, and all of the security issues that go with it, then a rebuttal that says 'Nope, GraphQL is more secure' isn't going to cut water if the only specification of security is locked away. Particularly since people may be accidentally throwing their GraphQL client side not realizing that there are security issues involved at all (since Peter Hunt says it's more secure for example)