Enterprises looking to modernize their APIs are increasingly switching from the REST architecture to the open-source data query and manipulation language GraphQL. While the transition makes sense – GraphQL is more flexible, scalable, and easier for developers to use – attackers are also seeing new opportunities for mischief. Developer teams must avoid the mistake many organizations made with Kubernetes: rushing into a new, advantageous, and developer-friendly technology while leaving security considerations on the back burner.
Those finding themselves within the developer led GraphQL movement must understand the current threats facing them and recognize that GraphQL increases their own security responsibilities. Enterprises that rush to adopt GraphQL without implementing a security strategy put themselves at a high risk of suffering unpleasant consequences—especially as they scale.
Let’s look at the top GraphQL security weaknesses that attackers will seek to exploit, and how developers and their organizations can minimize the risks.
What GraphQL vulnerability data is saying right now
Vulnerability data sourced from the MITRE CVE database and the HackerOne Hacktivity portal offers valuable insights into how attackers seek to infiltrate GraphQL, and how developer, DevOps, and DevSecOps teams should set up their defense. The following analysis takes a close look at vulnerability exploits available to attackers across GraphQL servers, clients, and additional components.
While not comprehensive, the MITRE CVE database provides a robust-enough-to-be-very-useful data source for understanding GraphQL vulnerabilities. Looking at the database’s 45 tracked GraphQL vulnerabilities (the first identified back in 2019), authorization bypass vulnerabilities represent a clear majority, accounting for 54.8% of the total. Denial-of-service (DoS) vulnerabilities follow with 16.7%. Rounding out the recognized vulnerability classes, 9.5% of vulnerabilities relate to information disclosure, 7.1% to code execution, 7.1% to cross-site request forgery, and 4.8% to injection.
The latest data from the Hacktivity portal, which collects researcher-reported vulnerabilities, reveals similar findings. This data shows an even greater prominence of authorization bypass risks, with 87% of known GraphQL vulnerabilities falling into this class. DoS vulnerabilities take second place with 7%. Race condition and session management vulnerabilities account for 2.8% each.
The bug bounty-driven nature of the Hacktivity portal may skew these results to a degree: authorization vulnerabilities can directly put sensitive data at risk, earning premium bounties for researchers. Testing for DoS vulnerabilities is also largely prohibited as that testing could do real harm, likely reducing the number of those vulnerabilities represented in this data.
These findings make it clear that developers using GraphQL must secure their deployments by implementing effective schema-based access control to limit access by function and counter authorization bypass attacks. Dynamic rate-limiting should also be in place to defeat DoS attacks. Backing these capabilities with granular analytics and maintaining activity logs for robust visibility will further ensure that teams can thwart unauthorized behavior before attackers can do harm.
GraphQL API attacker reconnaissance can give attackers away
Attackers have sophisticated, automated methods of prodding GraphQL deployments for security weaknesses. Passive research on an organization, innocuous queries to assess application behavior and locating GraphQL APIs by simple deduction are all part of an attacker’s toolbox right now. In doing so, they are identifying the technologies in use and further clues on how to shape a successful attack.
These attacker activities go undetected because standard API security gateways do nothing to contextualize incoming GraphQL request queries. This amounts to a blind spot for teams working with APIs and significantly raises the risk of compliance failures.
For example, if developers accidentally leave access credentials within code available in public repositories, attackers that discover them have good reason to celebrate. GraphQL queries sent to an application—even if invalid—will tell attackers whether GraphQL is in use. Attackers can also automatically query multiple endpoints where GraphQL is likely to reside (such as /graphql, /query, /api, /playground, /console, and /graphiql), and server responses will tell attackers when they’ve found what they’re looking for.
But the automated queries that attackers rely on will show up as anomalous behavior if the right GraphQL security strategy is in place. By implementing safeguards that flag invalid queries and bulk traffic targeting multiple endpoints—many of which don’t exist—developers and organizations can detect and block (or mitigate) attacks before exploits can escalate.
Rate-limiting the number of object requests and operations an application can make is an effective measure for securing GraphQL API endpoints (and should be done at object-level, not call-level). Attackers may be able to play the detection game and find ripe GraphQL targets, but teams with the right security can play it better and stop attacks in their tracks.
GraphQL security demands prioritization
For organizations using GraphQL, it’s crucial to understand the nature of the specific threats to GraphQL APIs and applications, and to have specific security measures prepared to address those risks.
Securing GraphQL is only difficult if it isn’t given the priority it deserves from the beginning of adoption. With the right strategy and processes actively monitoring traffic for anomalous activity while securing access control (and other known avenues of attack), developers can securely take advantage of the GraphQL benefits they’re after—and do so at scale.