gRPC: The DDoS Blind Spot Your WAF Can't See

Your WAF inspects HTTP. gRPC speaks protobuf over HTTP/2. The WAF sees frames, not payloads. That gap is an attack surface, and it is growing every quarter as more organizations adopt gRPC for their microservices, mobile backends, and internal APIs.

We built a tool called grpc_stress.go with five distinct attack modes targeting gRPC services. Every one of them passes through standard WAF configurations without triggering a single rule. This post explains why that happens, what the five modes do, and what you can do about it.

Why gRPC Is Different

gRPC is Google's open-source RPC framework, now the default communication layer for Kubernetes services, mobile app backends, and an increasing number of public-facing APIs. If you work with microservices, you almost certainly have gRPC in your stack.

At the protocol level, gRPC works like this:

1. Transport: HTTP/2 carries gRPC calls as standard HTTP/2 frames. The content type is application/grpc.
2. Serialization: Request and response bodies are encoded using Protocol Buffers (protobuf), a binary serialization format. Not JSON. Not XML. Binary.
3. Streaming: gRPC natively supports four communication patterns: unary (single request, single response), server streaming, client streaming, and bidirectional streaming. A single HTTP/2 connection can multiplex hundreds of concurrent streams.
4. Metadata: gRPC uses HTTP/2 headers for metadata, including deadlines, authentication tokens, and custom key-value pairs.

This architecture creates a fundamental problem for WAFs. Traditional WAFs were designed to inspect HTTP/1.1 requests with text-based bodies (form data, JSON, XML). They parse URL paths, query parameters, cookies, and request bodies to detect SQL injection, XSS, command injection, and other attack patterns.

gRPC breaks every one of those assumptions.

The 5 Attack Modes

We built grpc_stress.go to systematically test each dimension of the gRPC attack surface. Each mode exploits a different aspect of the protocol, and each is invisible to HTTP-layer inspection.

Mode 1: Stream Flooding

Mode 2: Large Message Attack

Mode 3: Deadline Abuse

Mode 4: Metadata Flooding

Mode 5: Connection Flooding

Why WAFs Cannot Help

To understand why these five attack modes bypass WAFs, consider what a WAF actually inspects and what it does not.

The critical gap is in the bottom three rows. WAFs operating at the HTTP layer can see the HTTP/2 frames and headers, but they cannot parse the protobuf payload, understand the gRPC framing, or interpret gRPC-specific semantics like deadlines and streaming behavior.

Vendor-Specific Gaps

We tested how the four most common WAF vendors handle gRPC traffic. The results are consistent.

Who Is Exposed?

gRPC adoption has accelerated rapidly over the past five years. The protocol is no longer limited to Google's internal services. It is a standard component of modern infrastructure.

Organizations running gRPC in production typically fall into these categories:

• Kubernetes-native companies: gRPC is the default inter-service communication protocol in many Kubernetes deployments. Service meshes like Istio, Linkerd, and Envoy use gRPC for both data plane and control plane communication.
• Mobile app backends: gRPC's efficient binary serialization and bidirectional streaming make it popular for mobile APIs where bandwidth and battery life matter. If your mobile app communicates with a backend, there is a meaningful chance it uses gRPC.
• Fintech and trading platforms: Low-latency requirements drive gRPC adoption in financial services. Order execution, market data streaming, and inter-service calls in trading systems frequently use gRPC.
• IoT and telemetry: Devices streaming sensor data to cloud backends increasingly use gRPC for its efficient serialization and streaming capabilities.
• Public APIs: Google Cloud APIs, Buf Connect, and a growing number of third-party services offer gRPC endpoints alongside REST. Some offer gRPC exclusively.

The pattern is clear. Any organization that has adopted microservices in the past five years likely has gRPC in its stack. Many of these organizations protect their HTTP/REST endpoints with WAFs while leaving gRPC services either unprotected or protected by WAFs that cannot inspect gRPC traffic meaningfully.

What You Can Do

Since WAFs cannot solve this problem at the protocol level, defense must come from the gRPC layer itself. Here are the concrete steps that address each attack mode.

1. Enforce Message Size Limits

The default 4 MB max message size is almost certainly too large for your service. Set explicit limits based on your actual payload sizes.

// Go (grpc-go)
server := grpc.NewServer(
    grpc.MaxRecvMsgSize(1 * 1024 * 1024),  // 1 MB max receive
    grpc.MaxSendMsgSize(1 * 1024 * 1024),  // 1 MB max send
)

// Java (grpc-java)
ServerBuilder.forPort(port)
    .maxInboundMessageSize(1 * 1024 * 1024)
    .build();

If your largest legitimate message is 50 KB, set the limit to 100 KB. There is no reason to accept 4 MB messages if your service never produces or consumes them.

2. Set and Enforce Deadlines

Reject requests with unreasonably short deadlines before processing begins. Implement server-side deadline validation in an interceptor.

// Go interceptor example
func deadlineInterceptor(
    ctx context.Context,
    req interface{},
    info *grpc.UnaryServerInfo,
    handler grpc.UnaryHandler,
) (interface{}, error) {
    deadline, ok := ctx.Deadline()
    if ok {
        remaining := time.Until(deadline)
        if remaining < 50*time.Millisecond {
            return nil, status.Errorf(
                codes.InvalidArgument,
                "deadline too short: %v", remaining,
            )
        }
    }
    return handler(ctx, req)
}

This stops deadline abuse at the door. If a request arrives with a 5ms deadline, the server rejects it immediately without starting any processing.

3. Limit Concurrent Streams

Control the HTTP/2 MAX_CONCURRENT_STREAMS setting to prevent stream flooding.

// Go
server := grpc.NewServer(
    grpc.MaxConcurrentStreams(50),  // Limit concurrent streams per connection
)

The default of 100 concurrent streams per connection is generous. For most services, 20-50 concurrent streams per connection is sufficient. Reducing this limit forces attackers to open more connections to achieve the same level of concurrency, making the attack more visible to network-level monitoring.

4. Implement gRPC-Aware Rate Limiting

Rate limit at the gRPC method level, not just the connection level. Different methods have different cost profiles. A ListOrders call is more expensive than a GetStatus call and should have a lower rate limit.

// Per-method rate limiting in interceptor
var methodLimits = map[string]rate.Limit{
    "/api.OrderService/ListOrders":  10,   // 10 req/s
    "/api.OrderService/GetOrder":    100,  // 100 req/s
    "/api.OrderService/GetStatus":   200,  // 200 req/s
}

This is more effective than connection-level rate limiting because it accounts for the actual cost of each operation. A stream flood sending cheap requests is very different from a stream flood sending expensive queries.

5. Control Connection Counts

Limit the number of concurrent connections from a single source and implement connection-level keepalive enforcement.

// Go - keepalive enforcement
server := grpc.NewServer(
    grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{
        MinTime:             10 * time.Second,  // Minimum ping interval
        PermitWithoutStream: false,             // Disconnect idle connections
    }),
    grpc.KeepaliveParams(keepalive.ServerParameters{
        MaxConnectionIdle:     5 * time.Minute,  // Close idle connections
        MaxConnectionAge:      30 * time.Minute,  // Force reconnection periodically
        MaxConnectionAgeGrace: 5 * time.Second,   // Grace period for in-flight RPCs
    }),
)

Forcing periodic reconnection limits the damage from connection flooding and prevents individual connections from accumulating excessive state.

6. Limit Metadata Size

Set explicit limits on the size and count of metadata entries.

// Go
server := grpc.NewServer(
    grpc.MaxHeaderListSize(8192),  // 8 KB max header/metadata size
)

The default of 16 KB is more than most services need. Reducing this limit directly mitigates metadata flooding attacks.

The Complete Defense Matrix

Here is every attack mode mapped to the specific defense that mitigates it.

Notice the pattern. For three of five attack modes, WAFs provide no protection at all. For the remaining two, WAFs can partially help because the attack surface is at the HTTP/2 layer (headers and connections), where WAFs do have some visibility. But even for those two, gRPC-level defenses are more precise and effective.

The Bigger Picture

gRPC's DDoS blind spot is a symptom of a broader problem. Security tooling consistently lags protocol adoption. When the industry moved from HTTP/1.1 to HTTP/2, WAFs took years to add full HTTP/2 support. When REST APIs became the primary attack surface, WAFs were still optimized for HTML form submissions.

Now the industry is moving from REST to gRPC, from text-based to binary protocols, from request-response to streaming communication patterns. Security tooling has not caught up. The gap between what WAFs can inspect and what modern services actually speak is widening, not narrowing.

This is not a criticism of WAF vendors. Parsing protobuf at line rate without the schema definition is a genuinely hard problem. But it means that organizations adopting gRPC must take ownership of application-layer security themselves, rather than relying on infrastructure-level tools that were designed for a different protocol era.

The most dangerous security gap is the one between the protocol your application speaks and the protocol your security tools understand.