GraphQL is an open-source query language originally developed by Facebook that can be used to build APIs as an alternative to REST and SOAP. GraphQL has gained popularity since its inception in 2012 because of the native flexibility it offers to those building and calling the API. GraphQL servers and clients work together so that clients specify queries and servers validate data with GraphQL implementations working across various languages. Many companies use GraphQL including GitHub, Credit Karma, Intuit, and PayPal and a recent Gartner report shared that by 2025, more than 50% of enterprises will use GraphQL in production, up from less than 10% in 2021. This blog will cover the API security issues related to GraphQL APIs, and the best practices to protect your GraphQL APIs, including those threats covered in the Open Web Application Security Project OWASP API Security Top 10.
Why Use GraphQL?
GraphQL allows making multiple resource requests in a single query call, which saves a lot of time and bandwidth by reducing the number of network round trips to the server. It also helps to save waterfall network requests, where you need to resolve dependent resources on previous requests. This simplifies pulling large data resources into a framework allowing for pages like Facebook that have your profile, your friends’ data, online ads, and maps.
Where Are the API Security Issues for a GraphQL API?
When it comes to security, GraphQL APIs can potentially be incorrectly coded resulting in data compromise, access control issues, and other high-risk vulnerabilities. If we tackle some of the things we can see in the OWASP GraphQL Cheat Sheet that the Open Web Application Security Project (OWASP) publishes, we can see the sort of things that are needed, at a minimum to secure GraphQL APIs:
Injection can include OS Command Injection, SQL style injection, and File Inclusion type injections. This means that input validation is extremely important. Trusting client supplied data, without validation of some type, can result in any of these injection styles. The biggest takeaway from the OWASP GraphQL Cheat Sheet with regards to injection is to permit only certain input via a whitelist while gracefully rejecting poor input without excessive detail.
Denial of Service
Almost all denial-of-service attacks are based on resource consumption. If the server is tied up answering a billion requests a second, the server becomes slow and will crash, causing more resource consumption on the backup or load balancing devices. The good news is it is possible to stop denial-of-service attacks, including recursion attacks as well as standard resource consumption attacks with simple depth and request limits. Similarly adding pagination means the server doesn’t tie up memory with huge data fetches but only fetches one page at a time. There are many other techniques such as time outs that are simple to implement as well as moving to a content delivery network (CDN) front end provider.
Abuse of Broken Authorization
The simple rule for authorization is to validate that the end user is permitted to view/modify/create/delete, whatever they are touching, and they need to be validated on every request. This prevents Insecure direct object references (IDOR) attacks as well as mutation attacks.
Batching attacks are just as they sound, it is possible to figure out a few queries that work and throw them into one big query to have the server fetch the data in batches. This would allow for things like pulling data for all the records of a certain type. Batching allows for mass data exfiltration utilizing the victim API to do the heavy lifting.
Abuse of Insecure Defaults
My biggest suggestion is to make sure introspection isn’t enabled and to make sure the GraphQL playground is disabled or at a minimum, not public. As you test your APIs or simply just look at API requests and responses, put on your black hat and think what could be done to exploit the API. If you get an error message, read it. Does it help, do you have excessive errors enabled still?
Looking at the OWASP GraphQL Cheat Sheet and comparing your GraphQL environment to the suggestions there will certainly get you some great first steps. Where you go next is up to your own risk tolerance and security journey.
3 Steps to Protecting Graph QL APIs from Exploits
Comprehensive API protection requires a prevention-first approach that combines complete API visibility, runtime risk assessment, and remediation with native, inline attack prevention. In addition to the concepts outlined in the GraphQL Cheat Sheet, I have put together best practices that will help you to minimize potential security events associated with your GraphQL APIs:
- Step 1: API Discovery and Inventory Tracking: You cannot protect what you cannot see. Integration with any element of your API management infrastructure using either an inline or out-of-band data collection ensures all APIs, including GraphQL APIs are found, tracked, categorized, and assigned a respective owner.
- Step 2: API Risk Assessment and Remediation: Acting as a final security check, using predefined or custom risk assessment rules helps uncover and remediate APIs with weak authentication, exposing sensitive data, using verbose error messages, or out of conformance with published specifications.
- Step 3: Native, Inline Protection from Attacks and Vulnerability Exploits: Even a perfectly coded API can be attacked, strengthening the need to actively analyze and prevent attacks in real-time, using predefined, customizable policies with response options that include log, block, rate limit, geo-fence, header injection, or deception configured per app or API.
There’s More: Natively Protecting GraphQL APIs Against All OWASP API Security Top 10 Threats
When it comes to protecting your GraphQL APIs from attack, your API protection solution must include comprehensive and native protection against all the threats listed in the OWASP API Security Top 10.
Pitfalls to Avoid
- Avoid signature-based tools like WAFs that attackers can easily bypass.
- Stay away from solely DevOps-focused tools and lack a balanced approach to preventing threats while code is being fixed.
- Avoid using a vendor’s own test suite to validate this functionality. Create a battery of tests based on your APIs and the threats that can target them.
- Avoid API security tools that cannot natively mitigate threats and rely solely on third-party tools such as WAFs. Such tools cause a time delay between detection and response and higher than average false positives, which leave APIs vulnerable to compromise.
Cequence Unified API Protection (UAP) Solution
The Cequence Unified API Protection (UAP) solution is the only offering that addresses all phases of the API security lifecycle to protect your GraphQL APIs from attackers and eliminate unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption.
The Cequence UAP creates a complete runtime inventory of all managed and unmanaged APIs, known and previously unknown. Discovered APIs risks are flagged for remediation while sophisticated threats are detected and mitigated in real time. The result is complete protection from API threats that cause data loss, theft, fraud, and business disruption.
Get a Free Security Assessment of Your GraphQL API Attack Surface
Get an Attacker’s View into Your Organization
Never miss an update!