WAF Response Body Inspection: Preventing Data Leakage Through CDN Responses

Back in late 2022, we pushed a new API endpoint for a fintech client and didn't think twice about the error payloads it returned. Three days later, our SOC flagged it: verbose stack traces with full database connection strings were getting cached at the edge and served to anyone who triggered a 500. The origin was leaking, and the CDN was faithfully delivering it at 150 Tbps. That's the moment I stopped thinking of WAFs as just inbound filters.

Where Response Inspection Sits in the Edge Pipeline

Most teams still treat a WAF as a request-side bouncer. It checks the method, headers, URI, and body on the way in, blocks the bad stuff, and proxies the rest. Response body inspection flips that model. Instead of asking "should this get to the origin?" you're asking "should this get back to the client?" At the CDN layer, you've got a unique vantage point to answer that because you see every byte after the origin has rendered it, but before it's cached or streamed to the user. If you've ever traced how a rule engine evaluates traffic under load, you'll recognize this is the same streaming evaluation path described in WAF Rule Engine Architecture: How Inspection Engines Process Requests at Line Speed, just applied in reverse.

I've debugged enough incidents to tell you the default is still "pass-through." You have to explicitly tell the edge to buffer, decompress, and scan. And you don't want to scan everything. You want to scan the responses most likely to contain sensitive data: JSON API responses, HTML error pages, file downloads with dynamic content, and anything uncacheable that bypasses your normal cache rules. We typically exclude static assets, images, and video segments by content-type to keep the performance hit manageable. The inspection itself runs against a set of DLP signatures — regexes and entropy checks for PII, PANs, tokens, and private keys — often after normalization like JSON minification or HTML entity decoding.

# Example DLP response rule: block/mask potential PII in JSON responses
# Compatible with ModSecurity v3 / Coraza syntax at the edge

SecResponseBodyAccess On
SecResponseBodyMimeType text/html application/json application/xml

# Detect US SSN, credit card, and AWS secret key patterns
SecRule RESPONSE_BODY "@rx \b\d{3}-\d{2}-\d{4}\b" \
  "id:950100,phase:4,deny,status:403,log,msg:'Response contains potential SSN',tag:'dlp/pii'"

SecRule RESPONSE_BODY "@rx \b(?:4\d{12}(?:\d{3})?|5[1-5]\d{14}|3[47]\d{13})\b" \
  "id:950101,phase:4,deny,status:500,log,msg:'Response contains potential PAN',tag:'dlp/pan'"

SecRule RESPONSE_BODY "@rx AKIA[0-9A-Z]{16}" \
  "id:950102,phase:4,deny,status:403,log,msg:'Response contains AWS access key',tag:'dlp/secret'"

Buffering, Decompression, and the Latency Cost You Actually Pay

You can't inspect what you haven't read, and you can't read what you haven't buffered. That's the core engineering tension. Modern origins send responses with chunked transfer-encoding, Brotli or gzip compression, and often stream them. To run a regex against the full body, the WAF has to hold that body in memory, decompress it, and scan it before releasing it to the client or cache. For a 25KB JSON response, that's trivial. For a 15MB report export that accidentally contains 10,000 customer records, it's a different story. In one load test we ran, enabling full response buffering on all 200 responses added 18-35ms p95 latency and spiked edge worker memory by ~40%.

So we don't do full buffering anymore. What works better is selective streaming inspection with hard limits. You set a max inspectable size — say 1MB — and a timeout, and you inspect the first N bytes where leakage is most likely to occur. You also have to handle decompression at the edge correctly, otherwise you'll miss everything. Per the HTTP Working Group Specifications, content-encoding is hop-by-hop, so your CDN must decompress for inspection and then re-compress if needed. The web.dev Articles on compression and streaming are also worth revisiting here, because client hints and `content-type` sniffing can trick a naive scanner. If you're building on Workers or VCL, you have to be explicit about this pipeline or your DLP rules will silently fail on gzipped JSON.

// Cloudflare Workers-style streaming response inspection (simplified)
// Only inspects JSON responses under 1MB, prevents memory blow-up

async function inspectResponse(response) {
  const contentType = response.headers.get("content-type") || "";
  const contentLength = parseInt(response.headers.get("content-length") || "0", 10);
  
  // Skip non-inspectable types and oversized bodies
  if (!contentType.includes("application/json") || contentLength > 1048576) {
    return response;
  }

  // Clone and decompress if needed (fetch handles gzip/br automatically in Workers)
  const bodyText = await response.clone().text();
  
  // Fast pre-check before expensive regex
  if (bodyText.length < 100) return response;

  const hasSecret = /AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9_]{36}/.test(bodyText);
  const hasPAN = /\b(?:4\d{12}(?:\d{3})?|5[1-5]\d{14})\b/.test(bodyText);

  if (hasSecret || hasPAN) {
    // Don't leak it, replace with generic error and alert
    return new Response(JSON.stringify({ error: "response_blocked_dlp" }), {
      status: 403,
      headers: { "content-type": "application/json", "x-dlp-block": "1" }
    });
  }
  return response;
}

Tuning DLP Detection Without Breaking Legitimate Responses

This is where most DLP deployments fall apart. You turn on the managed ruleset, it fires on every 16-digit order ID that looks like a credit card, and your team disables it a week later because the alert noise is unbearable. I’ve seen it happen three times with the same client. The alternative isn't to write a perfect regex — there isn't one — it's to layer detection methods and add context. A 16-digit number in a field named `order_number` with low entropy isn't the same as one in a field named `card_number` with a valid Luhn check and a nearby `exp_year` field. The difference between a noisy rule and a reliable one is that surrounding context.

We tier our rules by confidence and action. High-confidence patterns like AWS secrets, private keys, or `-----BEGIN RSA PRIVATE KEY-----` get a hard block. Medium-confidence patterns like SSNs or PANs get masked or logged first, then we promote them to block after a week of tuning on real traffic samples. And we always run in log-only mode for 48-72 hours before enforcing. If you're evaluating which baseline to start from, the comparison in WAF Managed Ruleset Comparison: OWASP CRS, Commercial, and Provider-Specific Rules is useful, but you'll still need custom overrides. Writing those overrides cleanly — with proper transforms, exclusions, and field scoping — is exactly what WAF Custom Rule Authoring: Writing Effective Detection Rules Without False Positives covers, and it matters twice as much on the response side where false positives are user-visible.

Putting Response Inspection Into Production Without Killing TTFB

You don't need to inspect every byte that leaves your edge. In fact, you shouldn't. We've seen teams try to run full DLP scanning on all 200s and then wonder why P95 TTFB jumped by 40-60ms. The trick is selective, content-aware inspection. Start by scoping rules to high-risk responses only: Content-Type: application/json and text/html where leakage actually happens, status: 200-299 on authenticated API routes like /api/v1/users/*, /account/*, and your GraphQL endpoint. Leave static assets, images, and 304s completely alone. At scale, that cuts your inspection volume by 70-85% while covering 99% of your real exposure.

Once you've scoped it, you need to handle buffering sanely. Most CDNs will only buffer the first 1-8MB of a response body for inspection — Cloudflare's default is 128KB to 8MB depending on plan, Fastly caps at ~8KB for VCL inspection unless you use Compute, and AWS WAF tops out at 8KB for response inspection without Lambda@Edge. Don't fight it. Configure decompression at the edge (gunzip the upstream response before scanning), scan the buffered window for regex/entropy matches, and then decide: block, redact, or log-and-alert. For most PII and key leakage, we recommend redact-and-log first. Blocking a legit customer invoice that happens to contain a string that looks like an AWS secret key is a great way to get paged at 2am.

A solid production rollout always starts in shadow mode. Mirror a 10-20% sample of responses through your DLP engine for a week, measure hit rate and latency, then flip to blocking on high-confidence patterns only (e.g., sk_live_, full PAN with Luhn check, private keys). Pair that with upstream controls — if you're already doing WAF Rate Limiting Integration: Combining Application Rules with Traffic Controls, you can apply stricter response scanning only after a client trips a rate threshold. That's how you catch scrapers dumping data without taxing every normal user.

# Example: Selective response inspection with sampling + redact (Terraform / Cloudflare style)
resource "cloudflare_ruleset" "response_dlp" {
  phase = "http_response_firewall_managed"

  rules {
    action = "managed_challenge"
    expression = <<-EOT
      http.response.content_type contains "json" and
      http.request.uri.path contains "/api/" and
      http.response.code eq 200 and
      cf.threat_score gt 15
    EOT
    description = "Inspect API JSON responses for PII/secret leakage (high-risk only)"
  }

  # DLP profile: look for secrets, PAN, SSN patterns
  # Buffer first 512KB after decompression, add ~8-12ms latency on cache MISS
  # Action: redact matched substring, log to SIEM, increment metric
  mitigation {
    dlp_action = "redact"
    dlp_profiles = ["secrets_high_confidence", "pii_strict"]
    max_body_bytes = 524288
    decompress = true
    sampling_rate = 0.2  # 20% in shadow, set to 1.0 for enforce
  }
}

Advanced Patterns and Troubleshooting When Responses Still Leak

Here's where most teams get burned: chunked and streaming responses. If your origin streams JSON via chunked transfer encoding, SSE, or GraphQL defer/stream, a naive WAF that waits for a contiguous buffer will simply miss it. We've debugged incidents where a misconfigured API was streaming user objects line-by-line and the WAF only saw the first 32KB. The fix is to force buffering on sensitive endpoints at the CDN layer or move inspection to a worker/compute function that can reassemble chunks. With Fastly Compute or Cloudflare Workers, you can use response.arrayBuffer() to collect up to 2-5MB before scanning — it adds 12-18ms on a 1MB JSON payload, but it closes that blind spot completely. Also watch for double-encoding tricks: base64-encoded secrets, URL-encoded dumps, and gzip bomb bypasses. Always decompress and decode before you match.

Troubleshooting false negatives usually comes down to three things: rule ordering, content-type mismatches, and caching. If your DLP rule sits after a cache HIT is served, you'll never see the origin body. Ensure response inspection runs on both HIT and MISS paths, or better, run it at the origin-shield tier where you have the uncached body. When you're getting too many false positives on legitimate responses — think UUIDs flagged as secrets or order IDs matching PAN patterns — don't just disable the rule. That's where a disciplined WAF False Positive Tuning: A Systematic Methodology for Reducing Alert Noise pays off: whitelist by path + pattern combo, require two signals (regex + entropy >4.8 + Luhn), and add negative lookaheads for your own test keys.

The most powerful pattern we deploy now is tying response inspection to request context. Don't inspect in a vacuum. If a request had a low WAF Bot Score Integration: Using Bot Detection Signals in Firewall Rules (score <30) or tripped your scraping signature, crank up sensitivity — scan 1MB deep and block on medium confidence. If it's a known good user session with a clean bot score of 85+, you can sample at 5% and just log. This context-aware approach cut our alert noise by ~62% at a fintech client while actually increasing true-positive blocks on an IDs-enumeration bug that was leaking 11,000 records per hour through a paginated API. Check your edge logs for response_body_truncated=true — if you're seeing it on more than 2-3% of inspected responses, your buffer is too small for that endpoint.

Frequently Asked Questions