The gRPC WAF Coverage Gap

gRPC runs over HTTP/2 with protocol buffer encoding. Most WAF vendors inspect HTTP/1.1 and perform limited HTTP/2 inspection. Protocol buffer payloads are binary-encoded and opaque to WAF signature rules that inspect request body content. The result: a gRPC service exposed to the internet is likely to have zero WAF coverage regardless of what CDN or WAF sits in front of it. Every rate limit, request inspection, and bot detection rule in your WAF applies only to the HTTP traffic it can parse.

DDactic's scanner probes for gRPC endpoints as part of Stage 2 and Stage 3. Port 50051 (gRPC default) is included in the port scan. Any host that responds to a gRPC health check or returns a content-type: application/grpc header is flagged as a gRPC service. In assessments of organizations with microservice architectures, gRPC services exposed on internet-facing addresses (either directly or through API gateways that proxy gRPC without inspection) are a consistent finding.

Why gRPC Is Different

HTTP WAFs inspect request URLs, HTTP headers, and request body content to match attack signatures. gRPC uses HTTP/2 at the transport layer but encodes all payload data as protocol buffers -- a binary serialization format. The URL is the service method path (e.g., /package.ServiceName/MethodName), but the request body is binary-encoded and contains no querystring or form parameters. WAF signature rules for SQL injection, XSS, path traversal, and similar attacks match against text patterns in the request body. Binary protobuf encoding means these rules never match.

What gRPC Exposure Means for DDoS

A gRPC service with no WAF rate limiting is a direct origin exposure in DDoS terms. An attacker who identifies the service method (via source code, API documentation, or service reflection) can send an unlimited rate of requests to the method. If the method is computationally expensive (ML inference, database query, file processing), the attacker achieves the same compute exhaustion as an unprotected REST API endpoint -- with the additional advantage that no WAF rule will ever fire.

Envoy Proxy, commonly used as a sidecar in Kubernetes deployments, provides gRPC-native rate limiting via the rate limit service integration. This is the most practical mitigation for internet-exposed gRPC services: Envoy applies per-method rate limits at the service mesh level, independent of the HTTP WAF layer. AWS App Mesh and Google Cloud Traffic Director provide similar capabilities.

Hardening gRPC Services

• Remove gRPC services from internet-facing addresses unless explicitly required. Most gRPC services are inter-service communication that should be on internal networks only.
• If gRPC must be internet-accessible, place Envoy Proxy in front with per-method rate limiting configured.
• Disable gRPC server reflection in production -- it exposes the service interface analogously to GraphQL introspection.
• Use mutual TLS (mTLS) to authenticate callers. This does not prevent DDoS from authenticated clients but eliminates unauthenticated access.
• Apply connection-level rate limits at the load balancer layer: maximum concurrent connections per IP, maximum new connections per second per IP.

# Envoy rate limit configuration for gRPC methods
route_config:
  virtual_hosts:
  - name: grpc_service
    domains: ["*"]
    rate_limits:
    - actions:
      - remote_address: {}
    routes:
    - match:
        path: "/ml.InferenceService/Predict"
      route:
        cluster: ml_service_cluster
        rate_limits:
        - actions:
          - remote_address: {}
          - generic_key:
              descriptor_value: predict_method
# Rate limit service config: predict_method = 10/minute per IP