GraphQL APIs: Greater Flexibility Breeds New Security Woes
In complex application environments where APIs are the bridge between a multitude of data stores, containers, functions and microservices, the more flexible and dynamic the API is, the better. This is why GraphQL is an increasingly popular language among developers for writing APIs. But don’t be fooled: Considerable risk lurks behind all this development innovation.
By understanding how GraphQL works, you can start mitigating the potential security threats from within your organization — the kind that lead to large-scale data breaches.
GraphQL APIs Are a Map to the Sensitive Data
GraphQL is a development language that simplifies client communication with data stores and helps developers quickly implement changes without disrupting the rest of production. As the acronym “QL” implies, it is a query language. It operates like SQL and uses the API to request, insert and mutate data from the data store.
Originally developed by Facebook in 2012, and later released to the public in 2015, GraphQL was conceived as a stateless, SDL-based (Schema Definition Language) query language. While REST APIs make up the majority of most API ecosystems, that trend is changing as applications and cloud environments become more complex.
Unlike REST, GraphQL APIs pull data quickly, even on slower network connections, from a single request. On the frontend, GraphQL APIs are more flexible and easier to use, while on the backend, developers can quickly change or evolve the same API without disrupting the application.
The likeness to SQL is beneficial for many reasons, but that same benefit is also reason for concern. For instance, the query language provides the client with the ability to create sub-selections of related data, allowing the server to return the exact data the client specifies in a single request.
However, if the API does not have a strong model for enforcing object-level authorization, it’s possible to create sub-selections for related data that the client is not authorized to view. These vulnerabilities would be classified as both broken object-level authorization and excessive data exposure, the No. 1 and No. 3 issues, respectively, on the OWASP API Top 10. What’s more, GraphQL APIs provide attackers with ample opportunities to craft excessively complex and computationally expensive queries, which can result in application-layer distributed denial-of-service (DDoS) attacks.
Compounding the challenge, few security professionals know or understand how software development works, never mind the nuances of GraphQL. As a result, GraphQL APIs are often pushed into production without proper security auditing. Developers can assist the security team and take several steps to mitigate potential security incidents by being aware of the risks.
Internal-Facing GraphQL APIs: Beware the Threat Within
When written in GraphQL, APIs’ access to the data can be democratized through a common standard interface for different environments. This enables internal teams to immediately consume and work with the data in a flexible way that works for their specific needs. Therefore, it’s increasingly common for GraphQL to be used for internal-facing APIs. However, most developers won’t necessarily know how the client plans to use the data. They may not understand the various use cases or how the API they’ve written can be exploited.
Careless, compromised and malicious internal users are a notable threat to the security of an organization’s data, and APIs are a valuable pathway to that data. The majority of large data breaches are the result of a malicious actor gaining access to sensitive databases and using the flexibility of the SQL language to exfiltrate data.
For most organizations, internal-facing GraphQL APIs are a major blind spot to this attack vector, as they provide the same query language flexibility as SQL but lack specific detection and monitoring tools that are used to protect databases.
The challenge with insider threats is that the risk originates from legitimate access and user credentials. Insider threats have many faces: disgruntled employees, compromised users, carless users or motivated attackers.
It’s why in an online survey of 456 IT and engineering leaders across the U.S., U.K. and Japan, 52% say they’re worried about APIs exposing sensitive data to the wrong people. The concern is warranted: 58% of incidents that negatively impact sensitive data are caused by insider threats.
Secure APIs with Care, Treat Them Like Sensitive Data
While GraphQL’s flexibility makes development easier, it also compels developers to take a fresh look at securing APIs.
Organizations that process and store sensitive data are also responsible for the confidentiality, integrity and availability of that data. Often, this is governed through a variety of industry and government regulations. Although the specifics of each regulation may vary, they all generally focus on having robust audit and security-detection mechanisms in place. This involves logging all requests to data and being able to answer the questions of who accessed the data, what data was accessed, how and when they accessed it, and whether that access was appropriate.
Developers should be especially cautious and ensure that the identity of both the accessing service and originating client are preserved through the request audit. Implementing advanced API security controls can prevent the exploit of vulnerabilities in business logic and software dependencies, in addition to providing controls to mitigate application-layer DDoS attacks.
The flexibility afforded by GraphQL is advantageous for developers, but with innovation comes risk. Take a fresh look at securing GraphQL APIs by adopting a data security mindset to mitigate potential insider threats now and in the future.
