GraphQL and gRPC expose the limits of rule-based API WAFs

At a glance

What this is: This analysis shows that GraphQL and gRPC break rule-based WAF assumptions because abuse emerges during execution, not at the perimeter.

Why it matters: It matters because IAM, NHI, and application security teams need controls that correlate identities, service calls, and runtime behavior, not just request syntax.

👉 Read LEVO's analysis of why GraphQL and gRPC break rule-based WAFs

Context

GraphQL and gRPC are changing how applications expose data and service logic, but many security stacks still treat them as if they behave like traditional REST APIs. That mismatch matters because modern API risk often appears in valid requests that pass authentication, schema checks, and perimeter filtering, yet still produce excessive data exposure or computation.

The identity angle is direct: these protocols are heavily used by human users, service identities, and automated systems, so abuse is often expressed through legitimate credentials rather than malformed traffic. When security teams cannot correlate access intent with runtime behavior, they lose visibility into overuse, overreach, and delegated access that looks normal at the edge. That makes this a common failure mode in mature programmes, not a niche edge case.

Key questions

Q: What breaks when GraphQL and gRPC are protected only by rule-based WAFs?

A: Rule-based WAFs fail because they inspect request structure, while GraphQL and gRPC often express risk only during execution. A request can be valid, authenticated, and schema-compliant yet still expose too much data or trigger expensive resolver chains. The control gap is behavioural, so teams need runtime visibility and identity-aware policy, not just perimeter rules.

Q: Why do valid API requests still create breach risk?

A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object. If the application accepts an identifier or booking code as proof of access, attackers can modify that value and harvest data without tripping traditional perimeter controls.

Q: How do security teams know if API abuse controls are working?

A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load. Effective controls reduce both attack success rate and the time abuse can persist unnoticed.

Q: Should organisations replace WAFs with API monitoring for GraphQL and gRPC?

A: No. WAFs still matter for boundary validation, schema checks, and basic abuse suppression, but they are not sufficient on their own. Organisations should layer API discovery, runtime behavioural monitoring, and identity-aware enforcement on top of WAF controls so that execution-time abuse is visible and containable.

Technical breakdown

Why GraphQL changes the attack surface

GraphQL collapses many operations into a single endpoint and lets clients shape each query dynamically. That removes the stable endpoint-to-purpose mapping that many WAF rules depend on. A request can be syntactically valid, schema-compliant, and authenticated while still traversing nested relationships that expose data beyond the caller's intended scope. The real security question is not whether the request is allowed by the schema, but whether the execution path stays within the identity's legitimate business context.

Practical implication: enforce query depth, complexity, and field-level authorization, then correlate each request with the identity and data scope actually returned.

Why gRPC hides risk from perimeter inspection

gRPC serializes methods and payloads into protobuf over HTTP/2, which makes request meaning far less visible to boundary controls. The endpoint alone tells you little about what the call will do, and the service contract may not reveal how expensive or sensitive the operation becomes at runtime. A trusted service identity can repeatedly invoke the same method and extract large volumes of data without generating suspicious-looking traffic patterns. The risk is execution-time abuse, not malformed input.

Practical implication: pair protocol-aware inspection with service-level telemetry that measures method frequency, data volume, and downstream access patterns.

Why API WAFs still leave an execution gap

API WAFs improve parsing by understanding GraphQL and gRPC structure, but they still make decisions before execution. They can validate syntax, schemas, method allowlists, and some rate limits, yet they cannot see what downstream services return, whether authorization is applied consistently, or whether repeated requests form an abusive pattern over time. That is the core gap: edge controls inspect the request, while modern abuse emerges from what the application does with the request.

Practical implication: add runtime API monitoring and behavioural baselines so enforcement can react to access patterns instead of only static request properties.

Threat narrative

Attacker objective: The objective is to abuse legitimate API access paths to extract more data or processing value than the caller should be able to obtain.

1. Entry occurs through a fully valid GraphQL query or gRPC call that passes authentication and protocol validation.
2. Escalation happens when the caller uses the same legitimate interface to traverse more data, more objects, or more service methods than intended.
3. Impact follows as excessive data exposure, computation amplification, or unauthorized access that perimeter controls never flagged.

NHI Mgmt Group analysis

Rule-based inspection is no longer sufficient for modern API abuse. The central failure is not weak signatures, but a control model that assumes request structure reveals intent. GraphQL and gRPC defer meaning until execution, so abuse is often visible only in runtime behaviour, not at ingress. Practitioners should treat perimeter rule sets as a baseline, not a control boundary.

GraphQL creates a query-shape governance problem, not just a web security problem. A single endpoint can be used for low-risk lookups or for broad object traversal, and schema compliance alone does not distinguish the two. That makes field-level authorization, complexity limits, and identity-aware policy enforcement the relevant governance levers. Teams should align GraphQL controls with access intent, not just payload validity.

gRPC turns trusted service identities into a high-volume access risk. Because method semantics are encoded and often deployed inside trusted networks, misuse can look operationally normal while still exfiltrating sensitive data. This is where NHI governance intersects with API security: service accounts, tokens, and workload identities need runtime monitoring as much as human users do. Practitioners should assume authenticated service traffic can still be abusive.

Execution-time visibility is the named concept teams need to operationalise. The article exposes a broader execution-time visibility gap, where security controls can parse requests but cannot judge what happens after dispatch. That gap affects WAFs, API gateways, and even some IAM assumptions when identity is treated as proof of safe behaviour. Teams should instrument runtime access patterns across identities, services, and time.

Security programmes need to move from request filtering to behaviour governance. This is not only about blocking malicious traffic, but about understanding whether normal-looking usage is becoming abnormal at scale. The practical standard is behavioural assurance: can teams explain who accessed what, through which service, how often, and with what downstream effect? If not, the control plane is incomplete.

What this signals

Execution-time visibility gap: GraphQL and gRPC are a reminder that security controls built for request inspection will not keep pace with applications that defer meaning until runtime. For identity teams, the key question is whether service identities, user identities, and delegated access can be traced to actual behaviour, not just authenticated entry. That is increasingly the difference between theoretical access control and usable governance. See the control logic in NIST Cybersecurity Framework 2.0 and the API trust assumptions in NIST SP 800-207 Zero Trust Architecture.

As API estates become more dynamic, runtime inventory becomes a governance requirement rather than an operational convenience. Teams that cannot identify live GraphQL queries, gRPC methods, and the identities using them will continue to inherit blind spots from legacy perimeter thinking. The most durable response is to combine discovery, behavioural baselines, and access scope review across application and identity layers.

For NHI programmes, this topic also reinforces a broader governance pattern: trusted automation is not the same as safe automation. Service identities that can repeatedly call sensitive methods need the same visibility and review discipline as privileged human accounts. That is the practical extension of the control model, and it should shape how teams prioritise monitoring, offboarding, and access review.

For practitioners

• Define API-specific authorization boundaries Map GraphQL fields, resolvers, and gRPC methods to business-sensitive data and enforce authorization at that granularity, not just at the endpoint level.
• Add runtime behavioural baselines Track normal query depth, object traversal, method frequency, and data volume for each identity so low-and-slow abuse becomes detectable.
• Correlate service identities to data access Tie each service account or workload identity to the downstream records it can touch, then review for repeated access paths that exceed legitimate task scope.
• Use API discovery to close blind spots Continuously inventory live GraphQL queries and gRPC methods so undocumented or deprecated paths do not remain active attack surface.
• Treat WAFs as boundary controls only Keep rule-based WAF or API WAF policies for syntactic validation, but shift abuse detection and containment to runtime monitoring and response.

Key takeaways

• GraphQL and gRPC weaken rule-based WAFs because security-relevant intent appears during execution, not in the request boundary.
• Runtime abuse can stay fully authenticated and protocol-compliant while still exposing data, computation, or sensitive methods beyond intended scope.
• The control answer is behavioural visibility across identities, services, and time, with WAFs retained as a baseline rather than a final decision point.

Key terms

• GraphQL Query Depth: GraphQL query depth is the number of nested object layers a client can traverse in one request. Deep queries can look valid while reaching far more data than the user should reasonably access, so depth controls are a practical guardrail against over-fetching and resolver abuse.
• gRPC Method Semantics: gRPC method semantics describe the meaning and effect of a remote procedure call beyond its wire format. Because method names and payloads are encoded in service definitions and protobuf messages, security controls need service-level context to judge whether repeated calls are legitimate or abusive.
• Runtime API Monitoring: Runtime API monitoring inspects API traffic and behaviour while the service is live, rather than only during scheduled scans. It looks for abuse patterns, abnormal request sequences, and misused credentials, making it especially useful where machine-to-machine access changes faster than review cycles.
• Execution-Time Visibility: Execution-time visibility is the ability to see what an application or service does with a request after it passes the edge. It bridges the gap between authentication and actual data access, which is where many modern API abuses emerge.

What's in the full article

LEVO's full analysis covers the operational detail this post intentionally leaves for the source:

• How GraphQL query depth, field-level access, and resolver chains are evaluated in practice
• How gRPC method semantics, protobuf encoding, and service identity usage change detection requirements
• How runtime API monitoring and protection differ from boundary filtering in deployed environments
• Examples of abuse patterns that remain compliant with schemas and contracts but still cause harm

👉 LEVO's full post covers runtime monitoring, API protection, and the execution-time blind spots behind modern API abuse

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the runtime behaviour that modern application and API stacks now demand.