Skip to content

CONCEPT Cited by 1 source

Response-body sampling

What it is

Response-body sampling is the technique of inspecting a uniformly-random subset of outbound API responses — parsing the actual response body, not just request metadata or response codes — to detect anomalies, policy violations, or sensitive-data leaks in production traffic.

Distinct from:

  • Request sampling (looks at inputs only).
  • Structured audit logging (examines logged events, not the live response envelope).
  • Full-fidelity inspection (every response, typically too expensive in a high-QPS web tier).

Why sample, not inspect everything

  • Compute cost — JSON parsing + content scanning on every response at full QPS is non-trivial, especially if the scan requires async permission re-verification.
  • Latency budget — synchronous inspection adds p99 tails.
  • Statistical sufficiency — for population-level anomaly detection, uniform sampling at even 1% yields high signal quickly because real issues typically affect many requests; a bug that leaks data on one in ten million requests is a different threat model best handled by deterministic proofs.

Figma's posture (Source: sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure) uses configurable uniform-random sampling across request paths, with rate tuned to balance coverage against overhead.

Properties that make it work

  1. Uniform across request paths — so coverage isn't skewed toward the highest-QPS endpoints. Every handler gets inspected at the same rate.
  2. Configurable at runtime — turn up when investigating, turn down during peak traffic; no redeploy.
  3. Asynchronous verification — the after filter extracts candidates synchronously (cheap), the expensive verification runs in a background job.
  4. Non-blocking failure — sampling errors never fail the user-facing request.
  5. Rate-limited pipeline — the sampler itself is protected from request surges so it can't amplify overload.

Two response-body targets

Token matching (cheap, shape-based)

Scan JSON for strings matching a known high-entropy pattern. Suitable when the sensitive token has a recognizable character set and length — e.g., Figma's file identifiers. A regex suffices.

Value matching (precise, tracking-based)

Track exactly which sensitive values were loaded during the request (via ORM callbacks storing them in request-local storage), then compare against the serialized response. Precise: avoids coincidental-match false positives. Used by Response Sampling's Phase 2 with FigTag-tagged banned_from_clients columns.

Where to put the sampler

  • Application middleware (Figma's choice) — has direct access to the authenticated user, the response body, and the permissions engine. The only layer that can do user-aware checks cleanly.
  • Egress proxy / Envoy sidecar — simpler to deploy uniformly but loses user context and the permissions engine. Fine for content-shape checks, awkward for authz checks.
  • Client-side — too late; the data has already left the trusted boundary.

Coverage vs cost calculus

Sampling rate × traffic × per-sample-cost = sampler budget.

  • Raising the rate beyond the point where unique bugs stop reappearing has diminishing returns on new findings but linear overhead.
  • Most production systems land in the 0.1–10% range depending on what the sampler does per sample. Figma doesn't disclose theirs.

Integration with other services

If multiple services want to contribute sampled responses to one analysis pipeline, expose an internal endpoint taking a response payload + metadata (handled by the same inspection logic). Figma's LiveGraph does this — posts sampled responses to the Response Sampling endpoint so findings across services unify in one warehouse + triage dashboard, using the same schema + logging path regardless of source.

Seen in

Last updated · 200 distilled / 1,178 read