You need to protect your API regardless of how you structure it. Even with GraphQL's power, it involves complex configurations that can result in security vulnerabilities for applications. Unless these vulnerabilities are addressed, and your GraphQL is protected, your app may be prone to allowing malicious queries that compromise application servers.
In this article, we’ll go over the most common GraphQL security vulnerabilities and how you can take control of your API’s security.
The most common one on our list is common for a reason, as GraphQL itself doesn’t cover it. Developers are on their own to come up with user authentication within a GraphQL API, which can lead to issues. More commonly, this is found when resolvers in the API handle the functionality for authentication.
One of the most significant benefits GraphQL offers is that it can process multiple queries in a single request. But what happens when someone makes too many requests? GraphQL can only process so many at a time. Malicious attackers have figured out they can abuse this by sending a ton of requests at once, making brute-force attacks on a system much easier.
Another default feature of GraphQL is Introspection, aka the ability to query what resources are available in an API schema. This includes anything from data types, queries, fields, and even mutations. In most cases, this is an excellent tool for diagnostics, but if it isn’t disabled, you’re open to attacks.
An issue for any API, denial of service (DOS) attacks are a threat to any company. A malicious attacker can send millions of queries, all in a steady stream of information, overloading the system as a result. And, since GraphQL can have queries nested deep into the data, there’s a risk some of it might be exposed.
Naturally, another crucial part of maintaining an API is ensuring that any requests sent to it are valid before they’re processed. Without a check to ensure these queries are valid in the first place, systems are open to being overloaded with requests.
Now that we’ve covered some of the most significant issues with common vulnerabilities, what do we do about them? Let’s go over some of the most common (and practical) solutions.
The most significant impact you can make is to control what queries get sent to your API before it gets there. Here are three easy ways to get your queries under control:
⚠️ Limit Query Depth - It’s common for developers to end up with their queries looking somewhat cyclical, potentially showing more than they should. Limiting how deep these queries are nested can prevent them from being abused.
⚠️ Rate Limiting - In most cases, your users shouldn’t be making API requests at superhuman speeds. Disabling requests or throttling them after a certain point can dramatically reduce attacks on your system.
⚠️ Enabling Timeouts - Just like putting a kid in a time-out, enabling these acts similar to rate limiting. However, this is the Monopoly “Go to jail, do not collect $200” version, where users are locked out for some time.
The easiest way to prevent a user from causing damage to the system is by not trusting them. For each input in a query, you’ll want to validate it and make sure that they’re correct, to prevent users from slipping in malicious code and wreaking havoc.
This means checking to ensure that every part of a query is validated. If it’s supposed to be a date field, ensure the input matches DDMMYYYY (or however you implement it). Ideally, this should be done before they reach the API instead of being left to the resolvers when it’s potentially too late.
Another painless way to help prevent peeping toms in your API is limiting what they see. GraphQL’s introspection is a great benefit to developers for exploring their API while developing, but that’s it. Once your API hits production, it shouldn’t be enabled.
The same goes for error reporting, too. Limiting the information a potential attacker has access to makes their job much harder and can dissuade them from further prying. Plus, it isn’t that hard to implement, making it a win-win scenario.
Protection doesn’t just stop there, though. Limiting access to resources within your API is another way to help prevent a cyberattack. Your teams can accomplish this through Access Control as a security measure across your system. Here are three common types of Access Control:
Ideally, an organization should implement one or more security policies to keep access well-managed. You can have a fully-fledged security solution for easy management in any industry with all three.
Devii is dedicated to security, and we even baked it right into our code. We know GraphQL security is essential and want to ensure security is always kept in mind. Devii ships with Default Deny security policies so that nobody has access until you say so. Paired with the Devii Authorization Engine to help enforce role and policy-based access control and give your team peace of mind.
If you’re interested in taking your GraphQL security to the next level, sign up for early access.
Hero Images for Consideration: https://drive.google.com/drive/folders/1in5xmOc04jT8hbTqQBrFMXULgMw7jc8o?usp=share_link