How Web Application Firewalls Work: Filtering, Rules, and Protection

This article is for informational purposes only. Consult a qualified healthcare professional for medical advice, diagnosis, or treatment.

What Is a Web Application Firewall?

A web application firewall (WAF) is a security control that monitors, filters, and blocks HTTP/HTTPS traffic between web clients and web application servers. Unlike a traditional network firewall—which controls traffic based on IP addresses and TCP/UDP ports—a WAF operates at the application layer (Layer 7 of the OSI model), inspecting the content of web requests and responses to detect and block web-specific attacks. WAFs are specifically designed to protect against vulnerabilities in web applications including those listed in the OWASP Top 10, such as SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and remote file inclusion.

How a WAF Processes Traffic

A WAF intercepts every HTTP request directed to a protected application and evaluates it against a set of rules before forwarding it to the origin server. The inspection process includes:

• Request parsing: The WAF decodes and normalizes the request—URL decoding, HTML entity decoding, base64 decoding, Unicode normalization—to strip obfuscation that attackers use to bypass detection.
• Header inspection: HTTP request headers (User-Agent, Referer, X-Forwarded-For, Cookie) are examined for anomalies and known malicious patterns.
• URI and parameter inspection: Query string parameters and URL path components are examined for injection patterns, directory traversal sequences (../), and other attack strings.
• Request body inspection: POST body content—form data, JSON payloads, XML—is analyzed for malicious content.
• Rule evaluation and scoring: Each component is matched against configured rules. In anomaly scoring mode (used by ModSecurity + OWASP CRS), each rule match adds a numerical score; if the cumulative score exceeds a threshold, the request is blocked.
• Action enforcement: Based on rule evaluation, the WAF allows, blocks, challenges (CAPTCHA), rate-limits, or logs the request.

Security Models: Positive vs. Negative

OWASP Core Rule Set (CRS)

The OWASP ModSecurity Core Rule Set (CRS) is the most widely used open-source WAF rule set, compatible with ModSecurity, Coraza, and several commercial WAFs. CRS version 4 (2023) provides protection against the OWASP Top 10 and many other attack classes through over 200 paranoia-level-configurable rules. The CRS uses anomaly scoring: each triggered rule adds points; a configurable inbound and outbound anomaly score threshold determines when a request is blocked. At Paranoia Level 1 (default), the CRS has very low false positive rates suitable for most applications; higher paranoia levels add stricter rules at the cost of more potential false positives requiring tuning.

CRS specifically covers:

• SQL injection (SQLi) — patterns for UNION-based, error-based, time-based blind SQLi
• Cross-site scripting (XSS) — HTML, JavaScript, and DOM-based injection
• Remote code execution (RCE) — command injection, shell injection, PHP object injection
• Remote and local file inclusion (RFI/LFI) — path traversal, directory traversal
• HTTP protocol violations — malformed requests, unusual HTTP methods, oversized headers
• Scanning tool detection — automated scanner user-agents and behavioral patterns

WAF Deployment Modes

WAF Evasion Techniques

Understanding WAF evasion is important for tuning and for appreciating why WAFs are not a silver bullet:

• Encoding and obfuscation: URL-encoding (%27 for single quote), double encoding (%2527), HTML entities ('), case variation (SeLeCt), comment injection (SEL/**/ECT) can bypass naive signature matching. Modern WAFs with normalization layers handle most of these.
• HTTP parameter pollution: Sending the same parameter multiple times with different values; WAF and backend may interpret them differently.
• Chunked transfer encoding: Breaking a request body into chunks can confuse WAF parsing when the WAF does not fully reassemble the stream.
• JSON and XML injection: WAFs that lack robust JSON/XML parsing may miss injections in these content types.
• Slow-rate attacks: Slow HTTP attacks sending partial requests may evade detection while tying up web server connections.

Limitations and Complementary Controls

A WAF is not a substitute for secure application development. It provides a valuable defense-in-depth layer but cannot protect against:

• Logic flaws and access control vulnerabilities that use otherwise legitimate HTTP requests
• Authentication and session management weaknesses
• Insider threats and compromised administrative credentials
• Second-order SQL injection where malicious data is stored and later used in a query
• Zero-day application vulnerabilities for which no rule exists yet

WAFs should be deployed alongside application security testing (SAST, DAST, penetration testing), input validation in the application code, parameterized queries for database interactions, and a rigorous patch management program. Regular WAF log review and false positive tuning are essential for maintaining effectiveness without disrupting legitimate traffic.