Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
David Wallace: Okay. And your strengths?
Michael Scott: Well, my weaknesses are actually strengths.
David Wallace: Oh. Yes. Very good.
GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.
I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.
These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.
What is GraphQL?
GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.
“You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.
Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.
GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.
Unique Security Concerns
So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”
In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.
Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.
This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.
It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.
Tips to Mitigate Weaknesses
So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:
- Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
- Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
- Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
- Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
- Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.
Strengthening GraphQL Endpoints
API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.
“Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.
According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.
In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.
With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.
