So far, we've covered GraphQL Security Awareness and have understood that No, You Don't Need to Disable Introspection. Now, let's take a look at the different security knobs needed to guardrail a healthy GraphQL request.
GraphQL DoS (Denial of Service) attacks target GraphQL parsers, GraphQL resolvers, and the underlying DBs in a single API call. They include batching, nested, heavy and complex, N+1, and circular attacks which can bring your server down and affect server availability.
Fortunately, it is possible to protect your server from these attacks with the help of a set of guardrails and GraphQL usage-based rate-limiting.
Below is a list of security knobs that any GraphQL adopter should implement. Ideally, these configurations are set together with per-role access control to limit attacks.
As one of our favorite security knobs, limit directives help to guard against parser overload attacks. Overloading the parser with hundreds of directives can result in the server crashing without the request reaching the resolvers. (Credits: @unixhopper)
Helps to guard against nested and N+1 attacks that overload resolvers and DB with complexity and loops.
Helps to guard against alias attacks like overloading DB access for the same field or type.
Helps to guard against batch attacks like password guessing and OTA bypassing.
Offers fallback protection for complex requests by limiting the size of the request.
Make sense of your analytics and telemetry. While the uniqueness of the name can’t be enforced, having a name makes it much easier to gain context of the call and differentiate it from other calls when reviewing API usage.
We found that the most robust way to think about GraphQL Rate Limiting is to look at the server’s consumption and real usage. Counting each query’s returned objects against a timeframe limit (e.g. 1,000 credits per minute).
Credits can be configured in a few ways:
This approach works best with granular access control, where heavy-usage roles have a larger allowance as opposed to other roles or even unauthenticated calls.
Alternatively, if you are using GraphQL-JS, there are a few libraries that might help to predict the complexity of a query:
If all else fails, limit the size of the response.
Ready to defend against GraphQL server attacks? Inigo can help! Schedule a demo now.
Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.
Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.