-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2023-11] Add notes about security to GraphQL-over-HTTP spec #280
Comments
@martinbonnin and/or @glasser would you care to elaborate your concerns and/or submit non-normative notes to the GraphQL-over-HTTP spec regarding this. I'm happy to do editorial on them if you only have time for rough notes, I just want to ensure I'm capturing the important parts. |
Thanks for following up on this! I'll defer to @glasser for the details but my high level understanding is that some conditions make GraphQL requests more prone to CSRF issues like the ones described in this blog post:
For 1., might be worth requiring a content-type around here? |
Moving this to the GraphQL-over-HTTP WG |
I'm all for adding important security notes or references when appropriate to the spec as a note. As it particularly relates to |
@glasser Any interest in raising a PR for this? |
Sorry for taking so long to get back to this. Yes, I think it would be reasonable for me to write a PR for this. The key bit to me is that CSRF has become a much simpler problem to avoid in the modern REST/JSON API world, because API endpoints that require you to pass Because of this, my first suggestion will be that we change the POST section
from a SHOULD to a MUST. Do we know of any real GraphQL servers that don't already obey this? Secondly, I would add a non-normative section noting that GraphQL servers are generally immune to CSRF attacks, because side effects should only be accessible through mutations, mutations can only be executed by POSTs, and POST requests MUST have an appropriate Thirdly, I would consider noting that even allowing read-only GET requests from web browser clients without CORS preflighting can be problematic, due to timing attacks. It may be reasonable for most REST GET APIs to be accessible without a CORS preflight, because the only information code from a non-allowed origin can learn is how long the API took, and it's often not too hard to make the response time of a normal REST GET API relatively constant. But GraphQL queries are very flexible, and it's quite possible to design a query that can use timing to determine whether a given field returns null or not, by nesting under that field a complex set of recursive field selections that are only evaluated if the field returns non-null. So a non-normative suggestion that servers that use cookies/Basic Auth or are inaccessible from the public internet consider also requiring that GET operations contain a content-type header or another specific header such as I wish in retrospect that we had chosen Other existing implementations include the graphql-yoga implementation which uses I see that drupal-graphql also supports So concretely I think my changes would be the SHOULD to MUST change above, and a non-normative suggestion that servers should consider rejecting all requests that do not contain a Should I do this as two separate PRs (separating the SHOULD/MUST from the rest) or just as one? |
Awesome write-up; this all sounds great to me, except the SHOULD > MUST - I feel it's okay to say Standardizing |
Are there examples of popular GraphQL servers that accept POSTs with JSON bodies with no content-type header? The whole JS |
The GitHub API: curl \
-H 'Authorization: Bearer '$GITHUB_TOKEN \
-X POST \
https://api.github.com/graphql \
--data-binary '{"query":"{ organization(login:\"graphile\") { repository(name:\"crystal\") { description } } }"}' |
Hmm, but that API basically requires an Authorization header, right? |
Without one it seems to have a rate limit of zero currently. |
@martinbonnin and @glasser at Apollo were discussing CSRF, timing attacks, etc. Benjie feels that general HTTP concerns (security, rate limiting, cookies, etc etc) are concerns outside of the GraphQL-over-HTTP's spec, but Lee suggests that in the "art rather than science" vein we should have a non-normative section on how to think about security - handing off to follow best guidance on HTTP/internet security; but we should also add GraphQL specific notes - especially "this is secure because we omitted it".
(NOTE: @leebyron said "non-conformance" and "non-compliance", but I believe he meant "non-normative". Lee, please correct me if I misunderstood you.)
Note: Action Item issues are reviewed and closed during Working Group
meetings.
The text was updated successfully, but these errors were encountered: