Design Web Application Firewall

Hard45 min
1 / 30
System design answer

Design Web Application Firewall

Hard45 min30 sections
understanding•7 min read

Problem Statement and WAF Placement

How Problem Statement and WAF Placement (understanding) informs Web Application Firewall architecture and interviewer depth.

Problem Statement and WAF Placement

Define a multi-tenant L7 Web Application Firewall that inspects HTTP/HTTPS before origin, blocks OWASP-class attacks, and emits auditable security telemetry without breaking legitimate API traffic.

Where the WAF sits and what it must not break

A WAF is an inline L7 reverse proxy on the request path: it terminates (or inspects) HTTP/HTTPS before the request reaches the origin, applies a rule set, and decides allow / block / challenge / log. Placement is the first decision — inline blocking (can stop attacks, but adds latency and can take the site down if it misfires) versus out-of-band mirror (zero risk to traffic, but can only alert, not block). Production WAFs (Cloudflare, AWS WAF, Akamai, F5, ModSecurity) run inline and live or die on one number: the false-positive rate, because a WAF that blocks legitimate checkout traffic is a worse outage than the attack it prevents.

That tension — catch attacks vs never block real users — is the spine of the design, and it drives everything: a shadow/count-only mode to test rules before enforcing, per-endpoint allowlists for high-value flows, and a control-plane/data-plane split so a rule edit cannot stall the hot path. Anchor on real scale: ~2.5M requests/sec inspected, p99 inspection under ~8ms (you are in everyone's latency budget), block rate ~0.4%, and a false-positive budget under 0.01%.

Interview checkpoint

Open by placing the WAF (inline L7 reverse proxy, before origin) and naming the defining tension: catch OWASP attacks without blocking real users, measured as a sub-0.01% false-positive SLO. Then the levers that resolve it — shadow mode, per-endpoint allowlists, control/data-plane split — and the latency budget (p99 < 8ms) that forbids heavy per-request work.

Key Highlights

  • •Define a multi-tenant L7 Web Application Firewall that inspects HTTP/HTTPS befor
  • •Metrics: Peak RPS, p99 inspect, Block rate, FP budget
  • •Control plane vs data plane separation
Interview tip
When discussing Problem Statement and WAF Placement, quantify latency and false-positive budgets before naming vendors.
Avoid
Do not claim WAF replaces DDoS scrubbing or RASP—state boundaries clearly.

Section Rescue Kit

Buzzwords to use:

OWASP CRSVirtual Patching

Safe statements:

  • "I never fail-open WAF on unknown policy versions—stale known policy beats no inspection."
  • "Break-glass bypass always pairs MFA, TTL, and immutable audit."
  • "Regex for tenants uses RE2 with millisecond budgets, not unbounded PCRE."
Design Web Application Firewall - System Design | WinJob | WinJob