# Design a web application firewall: system design interview question

> HTTP attack filters: request interpretation, rapid rule updates, bounded inspection cost, and tenant isolation.

Source: https://sysround.com/questions/design-web-application-firewall
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a web application firewall that inspects HTTP traffic and blocks attacks such as SQL injection and cross-site scripting. The service must apply rule changes quickly and add little request latency."

## What to clarify first

- Traffic scale
- Read and write mix
- HTTP and TLS
- Latency
- Rule behavior
- Update consistency and durability
- Availability and stale rules
- Inspection limits
- Events and privacy
- Security scope

## Scope of a strong answer

Core requirements:

- Inspect HTTP requests with shared rules and tenant rules
- Block requests that match active attack rules
- Apply approved rule changes within a fixed time
- Record rule decisions without raw request data

Usually out of scope:

- Network-layer DDoS protection
- Response body inspection
- WebSocket messages and gRPC messages
- File content inspection
- Automatic discovery of new attack classes
- Application code fixes and browser security controls

## What interviewers probe

### Rule update deadlines

A shared change affects every tenant. Missed updates leave attack paths open, while partial updates can create rules that no operator approved.

### What the request means

An attacker can exploit differences between the firewall's interpretation and the origin's interpretation. Partial inspection can hide an attack.

### Latency during an attack

Attackers control request content and volume. One expensive rule can consume the CPU that all tenants need.

### Effects on customer traffic

An approved rule can still block valid requests. Rapid updates can spread that damage to every tenant.

## Common mistakes

- The design sends every request to a central rule service.
- The design permits requests after partial inspection or a parser failure.
- The rule engine permits unbounded work on attacker-controlled input.
- The design pins tenant policies to shared versions without a timely path for shared changes.
- The update path cannot prove enforcement or bound stale approval confirmations.
- The design claims that request filters prevent every SQL injection or cross-site scripting attack.

## The bar by level

- **Senior:** Defines shared activation semantics and meets the update deadline for affected tenants. Handles parser ambiguity, regex cost, and false positives. Verifies enforcement without delaying requests.
- **Staff+:** Proves approval durability and the stale-rule bound across partitions, delayed confirmations, clocks, and recovery. A single quorum-backed authority with fixed-expiry grants suffices. Justifies fleet capacity, shared update cost, and tenant isolation.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=web-application-firewall


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.