4 ms·

I think GraphQL might be unusually easy to accidentally get wrong. It handles very powerful untrusted input, by design. And it has enough features that many, m

I think GraphQL might be unusually easy to accidentally get wrong. It handles very powerful untrusted input, by design. And it has enough features that many, maybe most users don't know about all of them. This vulnerability wouldn't have happened if GraphQL didn't have a certain feature. I've implemented a simple GraphQL API and I didn't know about all the features that were involved here. I thought carefully about security, and I think I ultimately got it right, but there were a few false starts. Good software is not just possible to use correctly, but easy to use correctly. Software that's easy to use correctly will be more secure in practice, even if it has the same theoretical properties. I don't know if GraphQL would be better if it were less powerful. I'm not an expert. But it's worth considering the possibility.

holtalanm 5y ago
I honestly dont see any different between graphql and a REST api, in terms of what data is available where. if you have data you don't want publicly available, just.....don't include it in the model, and make sure your server implementation doesn't return it. It is possible I don't understand your comment, I suppose, but I really don't see what is so unique about graphql from a security standpoint.
- duckerude 5y ago
  > don't include it in the model They tried that, but they failed because they didn't know that it's possible to downcast from an interface. It's really hard to have that kind of problem in a dumb REST API. `return {"name": record.name}` does what it says with hardly any magic. But if I write `return record` there's a whole extra layer that grabs information out of record, and I have to trust that it only grabs the information I want it to grab. This is not to say that dumb REST APIs are definitely better. Having to do things manually also introduces risks.
  - true_religion 5y ago
    If your return a record it only will have data for the fields that you have implemented. When you are implementing graphql, every resolver has to check if the requesting user has the proper permissions to see anything. Fields aren’t created automatically by the graphql engine itself. You have to write them yourself, or use another tool that generates them for you at run or compile time. Also it’s not often said, but you can have fields return a union such as AdminRecods and PublicRecord or Record WithoutPrivateData.
kbenson 5y ago
Does GraphQL have a way to disable features? If so, it seems the sane way to go about implementing it for a set of data would be to enable the bare minimum features, and enable anything needed specifically after reviewing and researching what it allowed and how it interacted with other other features. If you can't, that seems like a very dangerous tool to use.
- true_religion 5y ago
  By default, no features are implemented in GraphQL. It’s a protocol like SQL or REST. You can adhere to the protocol, and doing so gains you an ecosystem of tools to use, but you have to actually build the nitty gritty bits yourself. Think of it this way: you can create a graphql schema for a calculator then implement it. It will do math, but store no data and definitely have nothing to do with a relational database.

holtalanm 5y ago

I honestly dont see any different between graphql and a REST api, in terms of what data is available where. if you have data you don't want publicly available, just.....don't include it in the model, and make sure your server implementation doesn't return it. It is possible I don't understand your comment, I suppose, but I really don't see what is so unique about graphql from a security standpoint.

duckerude 5y ago
> don't include it in the model They tried that, but they failed because they didn't know that it's possible to downcast from an interface. It's really hard to have that kind of problem in a dumb REST API. `return {"name": record.name}` does what it says with hardly any magic. But if I write `return record` there's a whole extra layer that grabs information out of record, and I have to trust that it only grabs the information I want it to grab. This is not to say that dumb REST APIs are definitely better. Having to do things manually also introduces risks.
- true_religion 5y ago
  If your return a record it only will have data for the fields that you have implemented. When you are implementing graphql, every resolver has to check if the requesting user has the proper permissions to see anything. Fields aren’t created automatically by the graphql engine itself. You have to write them yourself, or use another tool that generates them for you at run or compile time. Also it’s not often said, but you can have fields return a union such as AdminRecods and PublicRecord or Record WithoutPrivateData.

kbenson 5y ago

Does GraphQL have a way to disable features? If so, it seems the sane way to go about implementing it for a set of data would be to enable the bare minimum features, and enable anything needed specifically after reviewing and researching what it allowed and how it interacted with other other features. If you can't, that seems like a very dangerous tool to use.

true_religion 5y ago
By default, no features are implemented in GraphQL. It’s a protocol like SQL or REST. You can adhere to the protocol, and doing so gains you an ecosystem of tools to use, but you have to actually build the nitty gritty bits yourself. Think of it this way: you can create a graphql schema for a calculator then implement it. It will do math, but store no data and definitely have nothing to do with a relational database.