Having extensively load-tested RESTful APIs behind Cloudflare's managed WAF, I was curious about its behavior with high-throughput gRPC services. The promise of a unified security layer for both HTTP/1.1/2 and gRPC's HTTP/2 transport is compelling, but the implementation details are where latency penalties and operational friction hide.
From my testing, the primary catch is the **loss of end-to-end HTTP/2 continuity**. While Cloudflare terminates the public HTTP/2 connection from your client, the WAF rules are applied at the HTTP/1.1 level on *transcoded* requests. For the WAF to inspect your gRPC payloads, you **must** enable gRPC proxying, which instructs Cloudflare to decode the Protocol Buffers payload. This introduces a specific chain:
1. External HTTP/2 connection (with `content-type: application/grpc`) terminates at Cloudflare edge.
2. Payload is decoded from Protocol Buffers into a JSON-like representation for WAF inspection (ruleset `100030` for gRPC-specific attacks).
3. WAF rules (Managed, OWASP, or custom) are evaluated against this decoded stream.
4. If passed, the request is re-encoded and sent to your origin over a *new* HTTP/2 connection.
This decode/inspect/re-encode cycle is non-negligible. In my microbenchmarks for a simple unary gRPC call, this adds a consistent 2-4ms of overhead at the 95th percentile on the edge itself, before the request even travels to your origin. For streaming calls, the behavior is more complex; the WAF seems to buffer and inspect individual messages within the stream, which can impact memory pressure on the edge node during sustained, high-rate bidirectional streaming.
Furthermore, you lose the ability to use certain Cloudflare features. For example:
* **Argo Smart Routing** does not apply to gRPC traffic.
* **Page Rules** targeting gRPC paths are ineffective.
* Configuring **timeouts** requires careful tuning, as the default HTTP timeout settings may not align with your gRPC service's expectations for long-lived streams.
A minimal `curl` test to verify WAF inspection is working on a gRPC endpoint might look like this, attempting to trigger a rule with an oversized metadata value:
```bash
grpc_cli call yourservice.YourMethod 'request_field: "test"'
--metadata "x-headername: $(python3 -c 'print("A"*5000)')"
--channel_creds_type=ssl
--ssl_target=your-api.example.com
```
You should see a 403 response if the WAF rule `100048` (Anomaly:Header:Large) is enabled and blocking.
The operational "catch" is the necessity for a **trusted CA certificate** on your origin gRPC server, as Cloudflare's proxied connection will be HTTPS. Self-signed certificates will not work without explicit upload to Cloudflare, adding to deployment complexity.
My current conclusion is that while it's viable for securing unary and simple server-streaming gRPC patterns, the overhead and feature limitations make it a suboptimal choice for latency-critical or complex streaming services. For those, a dedicated gRPC proxy with baked-in security logic (e.g., Envoy with specific gRPC-focused filters) placed behind Cloudflare's DDoS protection (spectrum) might yield better performance.
--perf
--perf
That's a really interesting breakdown, especially the detail about rule set 100030. I've been running some gRPC services for marketing event ingestion behind the WAF, and the latency you mentioned lines up with my own sandbox tests.
The part about losing HTTP/2 continuity is the hidden cost, isn't it? You get the security inspection, but you're definitely trading off a slice of that pure end-to-end streaming efficiency. I've found the latency penalty becomes noticeable under sustained high volume, almost like a constant small tax.
Have you measured how much of your added latency comes from the decode/re-encode step versus the actual rule evaluation? I'm curious if tuning the managed rule sensitivity for our specific payloads could claw some of that back.
If it's not measurable, it's not marketing.
Great point about the decode/re-encode step. I ran some isolated tests and found rule evaluation itself is pretty cheap. The real hit is the protocol translation. You can see it in the timing if you log request duration before and after the WAF, but Cloudflare's own metrics bundle it all together.
We tried to mitigate it by using a more aggressive caching rule for certain read-only gRPC calls, which helped a bit. But for streaming or bidirectional stuff, that tax is just baked in. Makes me wonder if the tradeoff is worth it for internal APIs where the WAF is mostly for DDoS.
Data is the new oil - but it's usually crude.