What is a Web Application Firewall (WAF)?

How a WAF works

A WAF sits between the internet and a web application, acting as a reverse proxy. Every HTTP request passes through the WAF before reaching the application server. The WAF inspects the full request — URL, headers, cookies, query parameters, and body — against a set of rules, then makes a decision:

• Allow: The request appears legitimate and is forwarded to the application.
• Block: The request matches a known attack pattern and is dropped, returning a 403 to the attacker.
• Log/Alert: The request is suspicious but not definitively malicious — it is forwarded but an alert is raised for security review.
• Challenge: Some WAFs present a CAPTCHA or JavaScript challenge to verify the client is a human browser rather than an automated scanner.

Types of WAF deployment

1. 1
   Cloud-based WAF (SaaS) — Operated by a third-party vendor (Cloudflare, Akamai, AWS WAF, Imperva). Traffic is routed through the vendor's network before reaching your infrastructure. Easy to deploy, globally distributed, includes DDoS mitigation. No hardware to manage. The most common choice for web applications today.
2. 2
   Hardware WAF (Appliance) — A physical device installed in the data centre between the internet edge and application servers. High performance, no external traffic routing. Used by large enterprises and organisations with strict data sovereignty requirements. Higher upfront cost and maintenance burden.
3. 3
   Software WAF — Runs as software on the same server as the application (e.g., ModSecurity for Apache/Nginx, or built into frameworks). Lower cost, but adds processing overhead to the application server and doesn't provide DDoS absorbing capacity.

What a WAF blocks

A well-configured WAF can detect and block a wide range of web application attacks:

• SQL injection: Patterns like ' OR 1=1--, UNION SELECT, and encoded variants are matched against rule sets like OWASP ModSecurity Core Rule Set (CRS).
• Cross-site scripting (XSS): Requests containing <script> tags, JavaScript event handlers, or encoded script patterns in parameters or bodies.
• Directory traversal: Requests containing ../ sequences attempting to access files outside the web root.
• Application-layer DDoS: Rate limiting and bot detection to block floods of HTTP requests, credential stuffing, and content scraping.
• Known CVE exploits: Rule updates for newly disclosed vulnerabilities (virtual patching) — providing protection even before the application itself is patched.

WAF limitations

A WAF is a powerful layer but not a complete solution:

• Not a substitute for secure code: A WAF can be bypassed with sufficiently clever encoding, obfuscation, or novel attack patterns not covered by existing rules. Vulnerable code must still be fixed.
• Business logic attacks: WAFs cannot detect attacks that abuse legitimate application functionality — for example, a user exploiting a broken authorisation check to access other users' accounts. These look like valid requests.
• Encrypted traffic: A WAF must be able to decrypt HTTPS traffic to inspect it. Misconfigured TLS termination can create blind spots.
• False positives: Overly aggressive rules block legitimate traffic. Tuning is required, particularly for applications with unusual input patterns.