11.3 WAF Capabilities, Limits, and Rule Creation

11.3 WAF Capabilities, Limits, and Rule Creation

A web application firewall (WAF) is an HTTP/HTTPS policy engine that sits in front of a web application or API and allows, challenges, or blocks requests based on application-layer characteristics: method, path, headers, cookies, query string, and body. SAL1 Network and Web Protection expects you to know WAF deployments, detection capabilities and limits, and how to create WAF rules for security enforcement at a conceptual analyst level — not how to paste a vendor-specific rule language dump.

Chapter 9 already treated input validation, patching, and WAF as complementary defenses against cross-site scripting (XSS), SQL injection (SQLi), code injection, and path traversal. This section is the control-plane view: where the WAF lives, what a useful rule looks like in plain language, and which bugs it will never see.

Deployments

Reverse proxy / inline appliance. Traffic to the public hostname terminates TLS on the WAF or a load balancer, the WAF inspects HTTP, then it forwards to the origin. This is the classic inline deployment. If the WAF is down and fail-closed, the site is down; fail-open bypasses inspection.

Cloud / content-delivery WAF. Rules run at an edge network. Useful for volumetric abuse and geographic policy. Origin IPs must be restricted so attackers cannot skip the WAF.

Host-module or local agent. A module on the web server inspects requests in-process. Coverage is per host; shared responsibility with application owners is messy.

API gateway policies. JSON/XML schema checks, key rate limits, and method restrictions on /api/v1. Functionally a WAF for APIs even when the product is not branded as one.

Inline inspection only works if the WAF can see HTTP. End-to-end TLS to the origin without the WAF in the trust chain means the WAF sees ciphertext — the same encrypted-traffic limit as a network firewall.

Capabilities: what a WAF is good at

A WAF operates at the application layer, so compared with a 5-tuple firewall it can:

• Inspect paths (/admin, /.env, /wp-login.php), methods (block PUT/DELETE on a public site), and file extensions on uploads.
• Match negative-security (block known-bad) patterns: SQLi fragments, XSS tags, path ../ sequences, common scanner User-Agents.
• Apply positive-security (allow known-good) models: this parameter is an integer; this header must match a session cookie format.
• Rate-limit by IP, cookie, or API key to slow credential stuffing and scraping.
• Geo or IP allow/deny for administrative paths.
• Virtual patching: a rule that blocks an exploit pattern while the application waits for a code fix (the patching half of chapter 9).

It still cannot decide whether user 1001 is allowed to see order 1002. That is authorization, inside the application.

Creating WAF rules at analyst level

You will not be asked to produce a vendor dialect on SAL1. You will be asked to specify enforcement intent so an engineer or a playbook can implement it. Write rules as condition → action → log tag.

Rule A — block a SQLi pattern. Condition: query string or body parameter contains a SQL metacharacter sequence such as UNION SELECT, OR 1=1, or a comment token in a field that the application documents as numeric (for example id=). Action: block (HTTP 403), do not forward to origin. Log: full URL, matched parameter name (not necessarily the full password field), source IP, rule id sqli-union-or. Rationale: stops a class of chapter 9 injection probes at the edge. Tune immediately if a legitimate search feature needs SQL-like punctuation.

Rule B — rate-limit authentication. Condition: more than 100 requests per minute from one client IP to /login or /api/token. Action: challenge (bot management) or block for 15 minutes. Log: count, path, IP. Rationale: credential stuffing looks like many valid-looking POSTs; a firewall allow on 443 will not notice. Exclude the corporate NAT egress if all office users share one IP, or rate-limit on session/cookie instead.

Rule C — geo and path restriction. Condition: path prefix /admin or /wp-admin and source country or IP range is outside the operating footprint (and not on the VPN egress allowlist). Action: block. Log: country code, path. Rationale: administrative interfaces should not be a global guessing game. This is not a substitute for SSO and multi-factor authentication (MFA); it is a reduction in attack surface.

Optional companions, still conceptual: allow only GET and POST on the public site; cap upload size and block .php/.exe/.jsp in multipart filenames; require a correlation header on API calls.

Every rule needs an exception process. The first production week will produce false positives. Document who can add an allowlist entry, for how long, and how the exception is reviewed.

Limits: false positives, obfuscation, and authorization bugs

Business false positives. The surname O'Brien, a product named select, or a blog comment that discusses UNION queries can match a naive SQLi signature. If the SOC treats every WAF block as an incident, analysts drown. If engineering disables the rule globally, the control dies. The L1 skill is to classify: does this match look like a scanner (OR 1=1 on id) or a human name field? Escalate systematic false positives to the WAF owner with examples, not with a request to disable the whole rule.

Encrypted or obfuscated payloads. If TLS is not terminated at the WAF, there is nothing to match. Even with inspection, attackers encode (UNION rewritten as percent-encoding, nested Base64, JSON hex, chunked transfer tricks). A WAF that only string-matches clear UNION SELECT will miss a wrapped payload. Normalization (decode then inspect) helps; it is never complete.

Authorization bugs the WAF cannot see. Insecure direct object reference (IDOR) and broken access control: GET /api/orders/1002 with a valid session for user 1001. The request is well-formed HTTP, no injection, no flood, maybe even the same geo as legitimate users. The WAF forwards it. The application must enforce object-level authorization. Similarly, logic flaws (negative quantity, coupon stacking) are not signature events.

Other gaps. Authenticated feature abuse; business bots that look like browsers; vulnerabilities in origin apps that the WAF was never virtually patched for; attackers who hit the origin IP and skip the cloud WAF because origin restriction was skipped.

Complement to input validation and patching (chapter 9)

Recall the chapter 9 stack: input validation and output encoding in the application, parameterized queries / safe APIs, timely patching of frameworks, and WAF as a layer in front. The WAF is the control you can change this afternoon when a new SQLi pattern hits the news. The application fix is the control that still works if someone bypasses the WAF. SAL1 wants both pictures: you can propose Rule A as a virtual patch, and you still ticket developers to parameterize the id query.

For case notes, a useful L1 sentence is: WAF block on UNION SELECT against /search?id= — true positive probe, origin never saw the payload if inline-block worked, still need to confirm the application uses parameterized queries so a bypass would fail.

Worked decision table

WAF is mandatory vocabulary for Network and Web Protection. Treat it as a sharp, limited knife: excellent at HTTP abuse you can describe in a rule, silent on authorization, and noisy if you never budget for exceptions.