How to Protect Popular Query Language GraphQL APIs from Exploits


Many companies, including GitHub, Credit Karma, Intuit, and PayPal, use GraphQL, which is a query language for application programming interfaces (APIs) and a runtime for answering queries with existing data.

A recent report from Gartner shared that by 2025, more than 50% of companies will be using GraphQL in production, up from less than 10% in 2021. Originally developed by Facebook, GraphQL is used to create programming interfaces for ‘applications (API) as an alternative. to the best known REST and SOAP.

The open-source language has grown in popularity since its inception in 2012 because of what its native flexibility offers those who create and call the API. GraphQL servers and clients work together so that clients specify queries and servers validate data with GraphQL implementations working in different languages.

So let’s take a look at API security issues related to GraphQL APIs and best practices for protecting GraphQL APIs, including the threats covered in the Open Web Application Security Project OWASP API Security Top 10.

GraphQL allows multiple resource requests to be made in a single query call, which saves time and bandwidth by reducing the number of network round trips to the server. It also saves cascading network requests, where IT has to resolve resources dependent on previous requests.

This simplifies extracting large data resources into a framework allowing pages like Facebook that have your profile, friends’ data, online advertisements and maps.

Potential security issues can arise because GraphQL APIs can be coded incorrectly, leading to data compromise, access control issues, and other high-risk vulnerabilities. By addressing some elements of the GraphQL cheat sheet published by the Open Web Application Security Project (OWASP), we can see what is needed at a minimum to secure GraphQL APIs.

Injection can include operating system command injection, SQL style injection, and file include type injections. This means that input validation is extremely important. Trusting client-provided data, without validation of some type, can result in one of these injection styles.

The biggest takeaway from the OWASP GraphQL cheat sheet is to allow only certain inputs via a whitelist while gracefully rejecting poor inputs without excessive detail.

Almost all denial of service attacks are based on resource consumption. If the server is busy responding to a billion requests per second, the server will become slow and crash, which will cause more resource consumption on backup or load balancing devices.

Fortunately, 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. Likewise, adding paging means that the server does not hog memory with huge data fetches, but only fetches one page at a time.

Many other techniques such as timeouts are simple to implement as well as switching to a content delivery network (CDN) front-end provider.

The simple authorization rule is to validate that the end user is authorized to view/modify/create/delete, anything they touch, and they must be validated on every request. This prevents insecure direct object reference (IDOR) attacks as well as mutation attacks.

For batch attacks, it is possible to determine a few queries that work and throw them into a large query for the server to fetch the data in batches. This would allow things like fetching data for all records of a certain type. Batch processing allows massive data exfiltration using the victim API to do the heavy lifting.

My main suggestion is to make sure introspection is not enabled and to make sure the GraphQL Playground is disabled or, at a minimum, not public. When testing APIs or just looking at API requests and responses, think about what could be done to exploit the API. If an error message appears, read it. Does that help, do you still have excessive errors enabled?

By looking at the OWASP GraphQL cheat sheet and comparing a GraphQL environment to the suggestions there, you will definitely advise some good first steps. The next step depends on one’s risk tolerance and safety journey.

Comprehensive API protection requires a prevention-focused approach that combines comprehensive API visibility, execution risk assessment, and remediation with native online attack prevention. I’ve collected best practices that will help you minimize potential security events associated with your GraphQL APIs:

Step 1: API Discovery and Inventory Tracking: We can’t protect what we can’t see. Integration with any piece of API management infrastructure using in-line or out-of-band data collection ensures that all APIs, including GraphQL APIs, are found, tracked, categorized and assigned to a respective owner.

2nd step: API risk assessment and remediation: Act as a final security check, using predefined or custom risk assessment rules, discover and remediate APIs with weak authentication, exposing sensitive data, using messages detailed errors or not conforming to published specifications.

Step 3: Native online protection against attacks and vulnerability exploits: even a perfectly coded API can be attacked, which reinforces the need to actively analyze and prevent attacks in real time, using predefined and customizable policies with options response options that include log, block, rate limit, geofence, header injection, or application-configured or API-configured deception.

When it comes to protecting GraphQL APIs from attacks, an API protection solution should include comprehensive, native protection against all threats listed in the OWASP API Security Top 10.

Pitfalls to avoid

# Avoid signature-based tools like WAFs that attackers can easily circumvent.

# Move away from DevOps-only tools and lack a balanced approach to preventing threats while remediating code.

# Avoid using a vendor’s own test suite to validate this feature. 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 result in above-average detection-to-response delay and false positives, leaving APIs vulnerable to compromise.

To select a Unified API Protection (UAP) solution, look for one that addresses all phases of the API security lifecycle to protect GraphQL APIs from attackers and eliminate unknown and unfamiliar security risks. mitigated which may result in data loss, fraud and business interruption.

A complete UAP should create a complete runtime inventory of all managed and unmanaged, known and previously unknown APIs. Discovered API risks should be flagged for remediation while sophisticated threats are detected and mitigated in real time.

The result will be comprehensive protection against API threats that cause data loss, theft, fraud, and business disruption.


Comments are closed.