WAF Inspection Logic

A Web Application Firewall (WAF) is not a firewall in the traditional sense. It is a sophisticated L7 Proxy that performs real-time semantic analysis of application-layer traffic. While a standard stateful firewall treats a TCP packet as a discrete unit of source/destination intent, a WAF views it as a fragment of a larger, potentially malicious conversation. The challenge of the WAF is bridging the "Semantic Gap": the difference between how a security appliance parses a request and how the backend application server interprets it. In 2026, this gap is where most high-value zero-day exploits reside.

The evolution of web technologies—from simple static HTML to complex, multiplexed HTTP/3 streams and JSON-heavy API interactions—has forced a total architectural overhaul of WAF inspection logic. We have moved beyond simple string searching into a domain where the WAF must act as a full-stack protocol emulator, a lexical analyzer, and a behavioral biometric sensor. This article provides a forensic deconstruction of these components, starting with the fundamental mathematics of pattern matching.

1. The Mathematics of Inspection: Aho-Corasick & DFA Optimization

At the core of every WAF engine lies a Pattern Matching Algorithm. Historically, this was implemented using standard Regular Expressions (PCRE). However, as attack signatures grew into the tens of thousands (e.g., OWASP Core Rule Set), standard regex engines suffered from Exponential Backtracking, a condition where a specifically crafted string can cause the CPU to spike to 100% while trying to resolve complex non-deterministic finite automaton (NFA) states.

NFA vs. DFA: The Time-Space Trade-off

The choice between NFA and DFA (Deterministic Finite Automaton) is the primary engineering trade-off in WAF design.

Aho-Corasick: The Multi-Pattern Engine

To handle thousands of static signatures simultaneously (like SQLi or XSS patterns), modern WAFs utilize the Aho-Corasick algorithm. By constructing a finite state machine—specifically a Trie with "failure links"—the WAF can identify all occurrences of all patterns in a single linear pass of the input string.

Where $g(q, a)$ is the transition function and $f(q)$ is the failure function, allowing the engine to "fail forward" to the next possible match without re-reading the input.

The total time to search is $O(n + m + k)$, where $n$ is the input length, $m$ is the total length of all patterns, and $k$ is the number of occurrences. This constant-time performance is what allows WAFs to scale to multi-gigabit throughput.

2. ReDoS: The Vulnerability of the Inspector

Ironically, the WAF itself is often the target of a Denial of Service attack known as Regular Expression Denial of Service (ReDoS). This occurs when an NFA-based engine is given a regex that exhibits "catastrophic backtracking."

Forensic investigation of WAF performance spikes often reveals malicious payloads designed not to bypass the rules, but to trap the WAF in a CPU-bound loop. Mitigation requires the use of non-backtracking engines (like Google's RE2 or Hyperscan) or strictly limiting the complexity and recursion depth of user-defined signatures.

3. ModSecurity & The Transformation Pipeline

The most widely deployed WAF engine is ModSecurity (now maintained by the community and various vendors). ModSecurity's power lies not just in matching, but in its Transformation Pipeline.

The SecRule Architecture

A standard ModSecurity rule (SecRule) consists of: Variables (what to look at), Operators (how to match), and Actions (what to do).

The $t:$ commands are Transformations. They are the WAF's primary defense against obfuscation. Before the regex is applied, the input is URL-decoded, converted to lowercase, and stripped of whitespace. This "Normalizes" the payload, forcing the attacker into a smaller, more predictable space.

The Five Phases of Inspection

Forensic efficiency requires blocking as early as possible. If a request can be blocked in Phase 1 based on a malicious User-Agent or Cookie, the WAF saves the significant CPU cost of parsing the Phase 2 request body.

4. Advanced Normalization: The Battle of Encodings

The most potent weapon against a WAF is Obfuscation. If a WAF is looking for <script>, an attacker will send %3cscript%3e (URL encoding), \u003cscript\u003e (Unicode), or even nested encodings like %253cscript%253e (Double URL encoding).

5. SQLi Detection: From Regex to Lexical AST Analysis

Detecting SQL Injection (SQLi) using regex is famously fragile. An attacker can change 1=1 to 'a'='a', 123-122=1, or CHAR(49)=CHAR(49). The next evolution is Lexical Analysis via libraries like libinjection.

Anomaly Scoring Models

Modern WAFs don't just block on a single match. They use Collaborative Anomaly Scoring. Each matched rule adds points to a total score.

If the score exceeds a threshold (e.g., 5), the request is blocked. This reduces false positives by allowing minor, low-confidence matches to pass unless they are part of a larger pattern of suspicious activity.

6. WAAP: API Forensics & JSON Schema Validation

The transition from WAF to WAAP (Web Application & API Protection) reflects the reality that most modern traffic is API-driven (JSON/REST/gRPC). Signature matching is ineffective inside a JSON blob if the WAF doesn't understand the structure.

• JSON Schema Enforcement: The WAF acts as a strict validator. If an API expects an object with three specific keys and receives four, the fourth is stripped or the request is blocked. This prevents Mass Assignment vulnerabilities.
• JWT Verification: WAAP engines can terminate and verify JSON Web Tokens at the edge. If the exp (expiration) has passed or the alg (algorithm) is changed to "none", the request never reaches the backend.
• Shadow API Discovery: By analyzing traffic patterns, the WAAP can identify undocumented endpoints (Shadow APIs) that were deployed by developers but never secured by the security team.

7. Machine Learning & Behavioral Analysis

The Positive Security Model uses Machine Learning to "learn" the baseline behavior of an application. Instead of rules for what is bad, it creates a profile of what is normal.

The Confusion Matrix of Security

Every WAF administrator lives in the tension of the Confusion Matrix. The goal is to maximize True Positives (TP) while minimizing False Positives (FP).

A high False Positive rate is often more damaging than a low True Positive rate, as it drives users away from the application and forces administrators to disable security rules entirely.

8. RASP: The Perimeter in the Code

The ultimate limit of a WAF is its external nature. It guesses what the code will do. Runtime Application Self-Protection (RASP) solves this by instrumenting the application runtime (JVM, CLR, or Node engine).

• Contextual Awareness: While a WAF sees a string, RASP sees that the string is being used specifically as a parameter in a java.sql.PreparedStatement.
• Zero False Positives: If the payload reaches a dangerous sink (like exec()) but has been successfully sanitized by the code, the WAF might block it unnecessarily, whereas RASP knows exactly when the execution becomes unsafe.

Conclusion: The Distributed Forensic Perimeter

The Web Application Firewall has transitioned from a centralized hardware appliance to a distributed fabric of Sidecar Proxies (Envoy) and eBPF Kernel Modules. The integration of 400G hardware acceleration via Hyperscan, AST-based lexical analysis, and behavioral ML has transformed the WAF into a multi-layered forensic engine.

For the infrastructure engineer of 2026, the goal is no longer just "filtering packets," but ensuring Semantic Integrity across the entire application stack. As the line between the network and the code continues to blur, the logic of inspection remains our only defense against an increasingly automated and intelligent threat landscape.