Are Your Developers Using GraphQL Without Your Knowledge?

Overview

Your organization could be running GraphQL right now…and you might not even know it. As a platform lead responsible for optimized operations, or a security operations person responsible for security of the environment, that’s not exactly a sleep-well-at-night scenario. It’s relatively simple for a lone developer to deploy GraphQL and, while you have no idea it’s happening, they almost certainly have no idea how to manage and secure GraphQL APIs.

Developers tend to prioritize efficiency and speed over security. These priorities have been the main drivers of GraphQL adoption (see, for example, PayPal’s GraphQL adoption story). The reasons are clear: GraphQL enables faster release of new versions to clients, easier API integration, easier testing, and an overall better developer experience. But while GraphQL increases developer productivity and improves end-user experiences, it is also a paradigm shift for platform teams who must ensure security and availability.

Developers’ priorities frequently conflict with those of platform teams. That’s not unique to GraphQL, but the difference is that when that happens with GraphQL, your existing web application gateway or other gateways won’t raise a red flag. A GraphQL server offering paths for attackers to expose data, or loading extremely resource-heavy burdens on your platform, could already be running and you would not know it because you will only see “200 OK” response codes (see why in our blog on GraphQL error handling).

Should you be worried about using GraphQL? Not at all, if you have the right tools and safeguards in place: deep analytics, tight access controls, and granular visibility into how GraphQL APIs use your resources. Without these, you cannot guarantee your SLAs and you certainly cannot meet compliance requirements because your GraphQL APIs would be exposed to injection attacks, vulnerabilities, and other kinds of attacks we discuss in other blogs.

GraphQL rewards organizations that implement best practices and place controls as early as possible. Getting GraphQL management and security right within a greenfield environment is far simpler than undoing hardcoded mistakes in legacy deployments later. It’s why we’ve built out all the GraphQL-specific capabilities required for platform teams and developers to benefit from a secure, resource-efficient, easily scalable GraphQL deployment from the start (and the visibility to know if your developers have, well, started without you).

Platform teams managing GraphQL should have these capabilities in place from Day One, or as soon as possible:

Access control

GraphQL access control is an essential Day One feature, but requires strategy and forethought. Going down the wrong path can lead to hairy situations, such as introducing overly-specific code inside resolvers and servers that becomes a challenge to remove. Deploying Inigo’s solution to get access control right from the start means avoiding major headaches in the future.

Many platform teams are also led astray by the false advice to disable introspection. Inigo’s schema-based access control features RBAC introspection separation to enforce access control at the edge and limits users’ visibility to the correct operations, types, and fields. GraphQL resolvers stay clean and tight, with complex code logic replaced by easily managed role-based declarative configurations. Query-level audit trails, data leak protection with PII detection, and remediation alerts ensure proper governance that aligns with compliance mandates.

Schema planning

GraphQL schema planning must be part of the development and API lifecycle from the onset in order to identify errors and protect against production failures that would cause degradation in service levels (and put SLA commitments at risk). Optimized schema planning is key not only to guaranteeing SLAs and reducing costs, but to the broader goals of API modernization. Using GraphQL without proper schema planning could results in poor results, causing your management to assume that GraphQL isn’t mature enough, rather than supporting your team in the process. Inigo’s enterprise-grade tools solve this issue by equipping platform teams and developers with access to real traffic usage data and unique business intelligence—enabling strong foundational and future schema planning. Teams see all their APIs and all the queries in depth, for ongoing control and schema optimization.

Federated subgraph visibility

If GraphQL does take root in your organization—but grows into a brownfield deployment with a federated graph before the platform team implements the right visibility tooling—you’ll need some extra help. A federated graph combines multiple subgraphs to expose a singular data graph via an API. Unfortunately for unprepared organizations, reaching this point means that the platform team has no visibility into what traffic goes to which subgraph within this federated architecture. When an issue occurs, such as slow performance or resource-gobbling server behavior, the team can’t see the cause or have the right information for resource allocation discussions. Tapping Inigo provides a clear breakdown of the resources, data, and load among federated subgraphs, making it simple to sort out otherwise painful issues.

Help your developers help themselves

For platform teams, developers that lack the tools to solve their own issues can be the biggest nightmare of all. Providing each developer with well-configured access control to address their own needs keeps issues off of the platform team’s plate. At the same time, powerful visibility allows platform teams to quickly solve any issues they do need to address. With Inigo, platform teams can eliminate friction with dev teams and ease the organizational learning curve toward secure and optimized GraphQL adoption, applying expertise from day one without needing to become GraphQL experts.