Securing a Graphql API #280
Conversation
|
This PR includes documentation updates New pages: |
keremgocen
left a comment
keremgocen
left a comment
There was a problem hiding this comment.
It's looking good so far and has valuable information. However there are a few typos and I think we can make it more practical with some code examples. I left a few comments.
|
|
||
| For the same reason it is advisable to avoid introspection and data field suggestions, it can make your API more secure to catch internal errors and redact which information you want to pass on to the end user. | ||
|
|
||
| For example, the following error reveals information XY: |
There was a problem hiding this comment.
Was this also a placeholder XY? feels like the JSON example here could be more illustrative?
|
|
||
| [source, graphql, indent=0] | ||
| ---- | ||
| // example |
| There are many ways and places to use timeouts. | ||
| Here are a few examples. | ||
|
|
||
| // examples |
|
|
||
| Follow the input validation methods summarized in the link:https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#input-validation[OWASP Cheat Sheet Series]. | ||
|
|
||
| // Examples? |
There was a problem hiding this comment.
also here, do we want an actual example?
| ---- | ||
| import depthLimit from 'graphql-depth-limit' | ||
| import express from 'express' | ||
| import graphqlHTTP from 'express-graphql' |
There was a problem hiding this comment.
should we maybe use a more up to date example here? we could replace the deprecated express-graphql with graphql-http, apparently. (cc: @mjfwebb)
There was a problem hiding this comment.
We'll replace this example with an example using GraphQL Armor
Co-authored-by: kerem <[email protected]>
| Returning large query result lists can negatively affect server performance. | ||
| For example, a query like the following would return a siginificant number of nodes: | ||
|
|
||
| [source, graphql, indent=0] | ||
| ---- | ||
| query { | ||
| order(first: 1000) { | ||
| orderID | ||
| products(last: 100) { | ||
| productName | ||
| productCategory | ||
| } | ||
| } | ||
| } | ||
| ---- | ||
|
|
||
| To avoid this, you can cap the input number directly in your resolvers, for example like this: | ||
|
|
||
| [source, graphql, indent=0] | ||
| ---- | ||
| // example | ||
| ---- | ||
|
|
||
| Alternatively, use a library such as link:https://github.com/joonhocho/graphql-input-number[graphql-input-number]: | ||
|
|
||
| [source, typescript, indent=0] | ||
| ---- | ||
| import { | ||
| GraphQLInputInt, | ||
| GraphQLInputFloat, | ||
| } from 'graphql-input-number'; | ||
|
|
||
| const argType = GraphQLInputInt({ | ||
| name: 'OneToNineInt', | ||
| min: 1, | ||
| max: 9, | ||
| }); | ||
|
|
||
| new GraphQLObjectType({ | ||
| name: 'Query', | ||
| fields: { | ||
| input: { | ||
| type: GraphQLInt, | ||
| args: { | ||
| number: { | ||
| type: argType, | ||
| }, | ||
| }, | ||
| resolve: (_, {number}) => { | ||
|
|
||
| // 'number' IS AN INT BETWEEN 1 to 9. | ||
|
|
||
| }; | ||
| }, | ||
| }, | ||
| }); | ||
| ---- |
There was a problem hiding this comment.
replace with type definition solution (server side)
mention: denial of service prevention
| ==== Query cost points | ||
|
|
||
| The link:https://shopify.dev/docs/api/usage/limits#the-leaky-bucket-algorithm[leaky bucket algorithm]. | ||
|
|
||
| ==== Query cost analysis | ||
|
|
||
| link:https://github.com/pa-bru/graphql-cost-analysis[graphql-cost-analysis] |
There was a problem hiding this comment.
link to graphql armor
| To prevent the API from not responding or falling victim to denial of service attacks, it is feasible to make use of timeouts. | ||
| This way, subsequent queries will not be blocked by a long-running previous query. | ||
|
|
||
| There are many ways and places to use timeouts. | ||
| Here are a few examples. | ||
|
|
||
| // examples |
There was a problem hiding this comment.
refer to transaction config in context
this PR is kinda dependent on #274 now
would be good to publish them simultaneously
274 has two js examples missing