Every second, web applications face thousands of malicious requests, from SQL injections to DDoS attacks. A Web Application Firewall (WAF) stands between your users and these threats, intelligently inspecting traffic and enforcing security policies before attacks ever reach your application. Understanding how a WAF works is essential for anyone designing secure systems.
Architecture Overview
A Web Application Firewall operates as a reverse proxy or inline filter that examines HTTP requests against a set of predefined and custom rules. The core architecture typically consists of four key layers: request ingestion, parsing and normalization, rule evaluation, and action execution. When a request arrives, the WAF first normalizes it by decoding various encodings, handling Unicode transformations, and standardizing formats. This prevents attackers from obfuscating their payloads.
The rule evaluation engine is where the real intelligence happens. The WAF maintains multiple rule sets, including built-in signatures for known attack patterns (like OWASP Top 10 vulnerabilities), rate limiting policies, and custom business logic rules. Rules can be simple string matches or complex expressions that evaluate multiple request attributes simultaneously. A request might be evaluated against dozens of rules in parallel, checking headers, body content, query parameters, cookies, and URL paths. The system assigns a threat score or applies immediate actions like blocking, logging, or rate limiting.
The final component is the action engine, which decides what happens to a request based on rule matches. Common actions include allowing the request through, blocking it with an error response, rate limiting the client, challenging with a CAPTCHA, or logging for manual review. Modern WAFs also include feedback mechanisms that learn from false positives and security analysts can refine rules over time. This flexibility makes WAFs adaptable to evolving threats while minimizing false positives that frustrate legitimate users.
Design Insight: Distinguishing Large File Uploads from Injection Attacks
This is where WAF design becomes particularly nuanced. A legitimate file upload might be several hundred megabytes, while a malicious request body injection attack could be just kilobytes but contain encoded SQL or script payloads. The WAF doesn't rely on size alone. Instead, it examines content-type headers, checks if the request declares itself as multipart form data, analyzes the actual content structure, and applies different rule sets based on context.
For a legitimate upload, the WAF validates that the request follows proper multipart boundaries, contains file metadata headers, and lacks suspicious patterns in non-file portions. For potential injection attacks, it inspects the request body itself for dangerous patterns, encoding sequences, or script signatures, regardless of size. Context matters enormously. A request claiming to be a JSON API call shouldn't have multipart boundaries, while a file upload missing proper boundary markers is immediately suspicious. Additionally, WAFs track upload history per user, applying behavioral analysis to detect anomalies like sudden massive uploads from unusual locations or at unusual times. This layered approach ensures large files pass through while tiny, malicious payloads get caught.
Watch the Full Design Process
See how this architecture comes together in real-time with AI-powered diagram generation:
Try It Yourself
Ready to design your own security systems? Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document.
This is Day 149 of a 365-day system design challenge. Each day brings new architectural patterns and real-world challenges to solve.
Top comments (0)