GraphQL, a powerful query language for APIs, has transformed how developers interact with data. Yet, with great power comes great responsibility — particularly regarding security. The OWASP API Security Top 10 2023 provides a valuable roadmap for ensuring all styles of APIs remain robust and secure. This article will walk you through these risks, how they pertain to GraphQL, and steps to mitigate them.

OWASP API Security Top 10 and GraphQL

API01: Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA), formerly known as Insecure Direct Object Reference (IDOR), is a significant risk in APIs. This vulnerability arises when an API exposes objects without proper authorization checks. An attacker can take advantage of this to access unauthorized data by manipulating input parameters, such as object IDs.

GraphQL Threat

GraphQL is designed to give the end user what they requested in the format it was requested. While this is a huge foundational principle, it makes issues of broken authorization much more impactful. When the user can request various data sources in a single request, it becomes easier to request very specific attack vectors and ask for data they should not have access to.

To resolve this threat, developers should implement fine-grained access control checks at the resolver level. Access control should be built into the API from day one. Libraries and tools such as graphql-shield could be deployed to ensure controls are in the right place and designed for the proper use case.

API02: Broken Authentication

This vulnerability pertains to flaws in authentication mechanisms, which could be abused or bypassed, allowing for a range of attacks. These attacks can be direct (as in data exfiltration) or indirect (as in denial of service attacks through bypassing authentication-based rate limiting).

GraphQL Threat

With GraphQL, authentication is paramount. The amount of access to resources and the control over how these resources are delivered in GraphQL requires a high level of authentication that is routinely checked and validated. Developers should never bundle authentication directly into the GraphQL logic, and more mature solutions for authentication, like OAuth, should be utilized to ensure a proper integration and security posture.

API03: Broken Object Property Level Authorization (BOPLA)

BOPLA highlights the risk of users accessing specific fields of an API object they aren’t authorized to view. This vulnerability combines issues like Excess Data Exposure and Mass Assignment. This inadequate validation of user authorization at the property level potentially leads to unwanted data exposure or manipulation.

GraphQL Threat

GraphQL allows users to request specific object properties, and without proper checks, sensitive properties could be exposed. To protect against this kind of attack, developers must employ appropriate property-level checks, especially for sensitive data fields. Static analysis tooling can be used to identify and mitigate potential data exposure as well as highlight critical areas that need ramped-up protection.

API04: Unrestricted Resource Consumption

APIs that don’t correctly limit or monitor their resource consumption are vulnerable to this type of attack. Overconsumption of resources can lead to denial of service and, in long-term attacks, can heighten operational costs to a damaging level.

GraphQL Threat

GraphQL relies entirely on the user to set expectations for queries and responses, and as such, the user has the power to issue quite expensive queries. Excessively deep or expensive queries that do not effectively use caching or rate-limiting can cause severe server strain, leading to Denial of Service. Excessive queries without proper caching can replicate this damage ad infinitum and raise production costs to astronomical levels.

Developers can implement rate limits, load balancing, caching, and other systems to reduce this on a practical level. At the base level, implementing controls for query complexity and depth can ensure no one query is so expensive that it can take down a system and can reduce the overall breadth and depth of denial of service style attacks.

API05: Broken Function Level Authorization (BFLA)

BFLA occurs when users can execute functions they’re not authorized for, like a regular user performing an admin-level task. These weaknesses in access control policies lead to unauthorized access to functions and the underlying protected data.

GraphQL Threat

GraphQL mutations can be abused if function-level authorization is absent or flawed, and this abuse can compound into further exposure through various combinatory tasks. Developers must ensure that GraphQL instances have appropriate resolver-level checks. Additionally, they must regularly review and test permissions at the function level to ensure that users can only do the minimum they must do to achieve the stated goal of that user group (adhering directly to the concept of least privilege).

API06: Unrestricted Access to Sensitive Business Flows

This kind of issue arises when business flows — for instance, purchasing an item — are exposed without consideration for what this means for the holistic API. The problem with this kind of flaw is that it’s not necessarily a configuration error — after all, purchasing an item may indeed be the entire point of the API. We saw this kind of flaw rampant during the launch of video game consoles in the last few years, where attackers utilized an endpoint and a botnet of devices to automatically buy up the entire stock of an item for later resale.

GraphQL Threat

This kind of attack particularly threatens GraphQL because of the nature of introspection. These kinds of attacks can only be done with known endpoints, and GraphQL often offers the endpoints on a silver platter to would-be attackers. Mitigating this kind of threat must happen at the business logic level. For instance, restricting the number of purchases by account or payment method, using heuristics to identify irregular purchasing patterns that might suggest a distributed attack, and more.

API07: Server Side Request Forgery (SSRF)

SSRF is when an attacker induces the server to make a request on their behalf, potentially accessing internal resources or exposing sensitive information. This potentially allows unrestricted access to critical functions.

GraphQL Threat

The unfortunate thing about GraphQL is that more user control over data queries and returns can turn GraphQL into a sort of accomplice for these kinds of attacks. Developers should be wary of implicitly trusting server-side requests, and should validate those requests the same way they would with any other user. In essence, a zero-trust model is the most appropriate for this kind of setup. Additional controls can happen at the business logical level by exposing only necessary resources outside of the core server — in essence, only the most necessary access for a server-side request can be made accessible, thereby limiting the potential threat escalation.

API08: Security Misconfiguration

This is a broad category that includes mistakenly exposing sensitive information or functionalities due to misconfigurations in the server or application. At its most basic, this category can broadly be defined as flaws that let attackers force the API to make unwanted requests to external resources.

GraphQL Threat

Introspection is a specific concern with GraphQL. By default, GraphQL often allows a level of introspection that, while great for the end user, has the potential for abuse, identification of new attack vectors, and escalations of discovered issues. Leaving this wide open could broadly be considered a security misconfiguration in terms of GraphQL.

Additional steps can be taken to validate and sanitize URIs in resolvers, restrict outbound requests at the network level where possible, ensure that there are no routes for privilege escalation, and others. The general best advice for security configuration exists in GraphQL as well. Ensure you adhere to the principle of least privilege and balance the need for accessibility with security and control.

API09: Improper Inventory Management

This vulnerability is about not maintaining a clear inventory of API versions, environments, and deprecated fields. Attackers can exploit this oversight to find and exploit old or unprotected API endpoints.

GraphQL Threat

GraphQL’s single endpoint can be both a boon and a bane, as outdated resolvers or types might be overlooked. Deprecated systems may not have the fixes and controls that newer ones do, and old systems based on old versions of authentication or authorization libraries and frameworks may be, by their very nature, insecure.

Developers can resolve this by using tools like Apollo Studio to control graphs and variants. Regularly deprecating and removing outdated resolvers and types manually can help in this process, although automated scanning for larger instances is also highly effective with a much lower operating ceiling.

API10: Unsafe Consumption of APIs

It’s essential to validate and sanitize data from third-party APIs. Treating data from external systems as trusted can introduce vulnerabilities to the system, especially when consuming these APIs without due diligence.

GraphQL Threat

If a GraphQL instance acts as a gateway to third-party services, any compromise of this connected service will compromise the GraphQL instance. To take this a step further, any external service that is relied upon for any amount of functionality necessarily increases this risk.

Developers should validate and sanitize all data from third-party APIs. External systems should be utilized within a zero-trust model and should be looked at suspectly at all times. Limiting GraphQL’s direct interaction with third-party services can mitigate this kind of attack. However, this also undermines the value of public APIs as a core concept, so this will always be a balancing act between security and utility.

Conclusion

GraphQL is extremely powerful, but with great power comes the need to secure it properly. By understanding the potential threats highlighted by the OWASP API Security Top 10 2023, GraphQL developers can ensure that their applications are efficient and robustly secure. Regular audits, combined with the implementation of best practices, will keep GraphQL deployments safe and sound.

What do you think about this piece? Have we missed some other solutions for implementing security processes against the OWASP Top Ten Risks? Let us know in the comments below!