-
Notifications
You must be signed in to change notification settings - Fork 43
Description
Earlier this month we experienced very poor performance and very slow queries on our public endpoint. It became clear the setup we had didn't have sufficient horsepower to handle large number of concurrent requests (especially expensive queries).
We beefed up our servers and enabled horizonal scaling (on the same machine with pm2 cluster) in additional to have network load balancer to horizontally scale to multiple nodes. This helped tremendously.
However it is not enough. We can certainly write good efficient graphql queries in our applications, but ultimately for a public endpoint we must assume there will always be some bad actors that want to abuse/disrupt operations.
There are many guides and best practices that we can and should follow. Here are some particularly good ones:
- https://www.apollographql.com/blog/graphql/security/9-ways-to-secure-your-graphql-api-security-checklist/
- https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#general-practices
- https://the-guild.dev/graphql/envelop/docs/guides/securing-your-graphql-api
One particular tool that stood out.
https://graphql.wtf/episodes/55-graphql-armor
Incidentally graphql-armor developer also provide a free public service https://graphql.security/ to scan graphql endpoints for vulnerabilities. This is how I originally came to realize the default configuration for our graphql-server is not very secure.
There is a wealth of guides and tools available at the-guild-dev to look at and learn from.