How Web Application Firewalls Work: The Inspection Pipeline
Web application firewalls inspect traffic at the application layer, allowing them to block logic-based attacks that network devices miss entirely.
A web application firewall sits between users and servers, parsing HTTP requests against rule sets. It blocks malicious payloads like cross-site scripting (XSS) attempts while allowing legitimate traffic. It operates as a reverse proxy, meaning it terminates the client connection before forwarding cleaned data to the origin server.
The Reverse Proxy Architecture
A web application firewall (WAF) functions as a reverse proxy. This means it presents itself to the outside world as the destination server, while the actual application server remains hidden behind it. When a user sends a request, the WAF accepts the connection. It then evaluates that request before deciding whether to forward it to the backend.
This architecture provides a critical security boundary. The WAF terminates the Transport Layer Security (TLS) session. By decrypting the traffic, the firewall can inspect the contents of the message. Without this decryption, encrypted payloads would remain invisible to inspection engines. However, this also means the WAF must manage cryptographic keys and certificates securely.
Stage 1: Connection and Decryption
The process begins when a client initiates a TCP connection. The WAF completes the handshake with the client. It establishes a separate connection to the origin server. This double-connection model allows the firewall to buffer the request. Buffering ensures the entire payload is received before any processing occurs.
If the traffic is encrypted, the WAF performs decryption. It uses private keys to decode the HTTPS stream into plain text. This step is computationally expensive. High-volume sites often offload this task to dedicated hardware or use shared secrets to reduce latency. The decrypted data is now available for deep inspection.
Stage 2: Request Parsing and Normalisation
Raw HTTP requests are often messy. Browsers and bots format headers differently. Some attackers intentionally obfuscate their payloads to bypass simple string matches. The WAF must normalise the request into a standard format. It decodes URL encoding, resolves path traversal sequences, and canonicalises header names.
Normalisation is where many basic filters fail. If the WAF does not decode every layer of encoding, an attacker can nest obfuscation techniques. This is known as double encoding. The firewall must recursively decode the input until no further decoding is possible. Only then can it accurately assess the intent of the request.
Stage 3: Rule Evaluation and Signature Matching
Once the request is normalised, the WAF compares it against a set of rules. These rules are often based on known attack patterns. For instance, a rule might flag any input containing specific SQL keywords in unexpected locations. This is signature-based detection. It is effective against common, well-documented threats.
The WAF checks the URL, headers, cookies, and body content. It looks for patterns associated with cross-site scripting (XSS) or command injection. If a match occurs, the firewall applies the configured action. This is usually a block, but it can also be a log or a challenge. Signature matching is fast but brittle. Attackers can modify their payload slightly to evade detection.
Stage 4: Semantic Analysis and Anomaly Detection
Signatures alone are insufficient for modern applications. The WAF performs semantic analysis to understand the context of the data. It builds a model of expected behaviour. For example, if a form field expects a numeric age, any alphabetic input is flagged. This is positive security modelling. It allows only known good inputs.
Anomaly detection looks for deviations from the baseline. If a user typically sends small POST requests but suddenly sends a massive payload, the WAF may block it. This helps catch zero-day exploits that do not match any known signature. However, this approach requires a learning period. During this time, the firewall may generate noise. Teams must tune these rules carefully to avoid disrupting business operations.
See also: Early Warning Signs of Cross-Site Scripting in Web Apps
Stage 5: Decision and Action
After evaluation, the WAF makes a decision. The options are typically allow, block, or monitor. If the request is blocked, the WAF returns an error page to the client. This page often contains a generic message to avoid revealing server details. The request never reaches the origin server.
If the request is allowed, the WAF may rewrite it. It can strip out suspicious headers or modify cookies to enforce security policies. This is known as virtual patching. It allows organisations to protect against vulnerabilities while they develop and deploy code fixes. This mechanism is particularly useful for addressing insecure direct object references (IDOR) where input validation is complex.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Connection | TLS handshake and decryption | If certificates are invalid or expired |
| Parsing | Normalisation and decoding | If obfuscation layers exceed processing limits |
| Evaluation | Matching against signatures | If rules are outdated or poorly tuned |
| Analysis | Behavioural baseline comparison | If the baseline is too noisy or inaccurate |
| Decision | Allow, block, or rewrite | If policy conflicts or latency thresholds are breached |
Stage 6: Logging and Telemetry
Every action taken by the WAF is logged. These logs include the source IP, timestamp, request details, and the rule that triggered the action. This data is vital for forensic analysis. It helps security teams understand attack trends. It also aids in tuning the firewall to reduce false positives.
Logs should be forwarded to a centralised security information and event management (SIEM) system. This allows for correlation with other security events. Without centralised logging, the WAF operates in isolation. Teams miss the broader context of an attack lifecycle. Effective logging requires storage capacity and retention policies that comply with legal requirements.
Limits and Operational Trade-offs
A WAF is not a substitute for secure code review. It sits in front of the application, not inside it. If the application has fundamental design flaws, the WAF may struggle to protect it. Complex business logic is difficult to model. A WAF cannot understand the intent behind a sequence of legitimate requests that together form an attack.
False positives are a significant operational burden. Blocking a legitimate user causes frustration and revenue loss. Teams must continuously tune rules to balance security and usability. This requires expertise in both web technologies and security. Additionally, WAFs add latency to every request. This performance impact must be managed through caching and optimisation.
Organisations should integrate WAFs into a broader defence strategy. This includes vulnerability disclosure policies to encourage responsible reporting. It also involves regular testing to ensure the firewall rules remain effective. Understanding directory listing exposure and file metadata risks helps in configuring the WAF to block information leakage.
Integration with Development Practices
The most effective WAF deployments involve close collaboration with development teams. Security rules should be derived from code analysis. If developers understand how the WAF protects their application, they can write cleaner code. This reduces the reliance on runtime protection.
Teams should use vulnerability severity ratings to prioritise which issues need immediate WAF rules. Critical flaws require immediate blocking rules. Lower severity issues can be addressed through long-term code fixes. This approach ensures that security efforts are focused where they matter most. It also helps in managing the complexity of the WAF configuration.
Key takeaways
- WAFs parse the semantic structure of requests, not just packet headers, enabling detection of application-layer exploits.
- Signature-based rules catch known threats, but anomaly detection is required to stop novel or polymorphic attacks.
- False positives remain a persistent operational risk, often requiring manual tuning to avoid blocking legitimate business transactions.
A web application firewall inspects and filters HTTP traffic to block application-layer attacks, but it requires continuous tuning to avoid blocking legitimate users. Integrate WAF rules with your development cycle to reduce reliance on runtime protection and improve code quality.
Frequently asked questions
Can a WAF protect against DDoS attacks?
A WAF can mitigate application-layer DDoS attacks by filtering malicious requests, but it cannot stop volumetric network-level attacks that saturate bandwidth.
Do WAFs slow down my website?
Yes, WAFs add latency due to decryption, parsing, and rule evaluation. Proper hardware sizing and caching can minimise this impact.
How often should WAF rules be updated?
Rules should be updated regularly to address new threats and reduce false positives. Monthly reviews are a common practice for most organisations.
Is a WAF enough to secure my web application?
No, a WAF is one layer of defence. You still need secure coding practices, regular patching, and network security to fully protect your application.
How this guide was produced: written by the Vector Bulletin editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
