API series – Inigo: With GraphQL power comes… developer responsibility for API security
This is a guest post for the Computer Weekly Developer Network’s API series written by Shahar Binyamin, CEO and co-founder at Inigo, a GraphQL security and management platform.
Binyamin writes in full as follows…
Developers are increasingly flocking to GraphQL to overcome REST API shortcomings.
Skillfully wielding the open source API data query language enables developers to build faster and more stable applications (and with more direct control of data). But – and there’s always a but – the developer-driven GraphQL movement is also pinning security duties that traditionally belonged to dedicated security and DevOps teams squarely in the hands of developers themselves.
Developers are often unaware of the degree to which GraphQL requires them to put on a security hat and focus on access control and operations alongside their more preferred duties of, well, building interesting applications.
Security & holistic access control
Deploying GraphQL for APIs asks organisations to adopt a new horizontal paradigm; the traditional separations among security, DevOps and developer teams are no longer present. In this new horizontal relationship, developers are responsible for both security and development.
While there are many guides available to help developers install the right GraphQL security knobs and features, implementing a holistic security and access control strategy is the key to success.
To protect GraphQL APIs, developers require schema-based access controls that work with database access controls, as well as with access controls for other APIs (such as REST and gRPC).
A holistic strategy that integrates these controls must also consider rate limiting and further protections against data scrapes. Plus, because access controls are written in code – and rather error-prone since schema is/are constantly changing – teams also need the right CI/CD tools to continuously check schema code and protect developers from their own mistakes.
Securing GraphQL also means going beyond traditional API security by contextualising clients’ API requests and responses, which carry valuable insights into attack surfaces and business logic.
Warning: avoid security-by-obfuscation
Too often, developers new to the API security roles that GraphQL imposes on them will adopt the naive approach that is security-by-obfuscation.
The idea is to disable GraphQL introspection, with the understanding that if the schema doesn’t offer information on what queries it supports then attackers won’t be able to figure this out otherwise.
This is a misconception.
Binyamin: A holistic strategy must consider rate limiting and further protections against data scrapes.
It’s been rooted in a lack of awareness of the attack surfaces that companies introduce when adopting GraphQL for APIs. Security-by-obfuscation does nothing: attackers know all they need to know and can still scrape data and create data leaks unless proper security and access control protections are in place. The knowledge of a system should not impair or lead to an elevation of risk of the overall system.
Scale through a federated lens
As GraphQL adoption scales, teams may suddenly find themselves with dozens of GraphQL API endpoints.
Scale makes it necessary to empower an enterprise architect with a federated lens that makes it more simple to oversee and protect the entire implementation. The goal is allowing various development teams to operate productively and independently, while securing any data they access via holistic controls.
Organisations that reach this high-scale GraphQL API usage must also introduce observability and query-level alerts to protect themselves against abusive API calls.
Developers must create an integrated and connected ecosystem where attacks targeting servers or data are rapidly detected and mitigated. And while query-level GraphQL injections are infrequent, security measures must be ready to defend systems with these types of vulnerabilities.
Developers shine as security experts
Too many developers rush into GraphQL for its powerful API advantages while leaving security as an afterthought. (In many ways, this adopt-first-secure-second push is similar to what happens with Kubernetes, with similar consequences.) GraphQL makes this particularly dangerous, because that afterthought isn’t then addressed by a dedicated security team, but must be handled by developers themselves.
By embracing best practices – including a holistic security and access control strategy, contextual understanding of API activity, and a federated lens for security oversight at scale – developers can shine in their security roles and effectively safeguard GraphQL API servers and data.