Malware
Web application firewall
Also called WAF.
Web application firewall is a filter in front of a site that inspects HTTP requests and drops the ones that look hostile. It buys time and cuts noise, but it is not a fix for vulnerable code.
How it is measured
Track what it blocks and what it misses: rules triggered, blocked requests by rule, false positives that stopped real users, and attacks seen in origin logs that passed through. Modes matter: log-only, challenge, or block.
Test by sending known probes at staging, such as a harmless SQL-style string or a path traversal sample, and see whether it is stopped. Also check whether the origin is reachable directly by IP; if so, the WAF can be bypassed.
Worked example
A WooCommerce store puts a WAF in front of its site. In week one, in log-only mode, it flags 5,200 requests, of which 40 are customers whose coupon codes contain an apostrophe that trips an SQL rule. The owner adds an exception for /cart and moves to block mode.
In week two the log shows 900 attempts at a plugin RCE path blocked. The origin server's IP is still public, though, and a scan of it directly returns the login page, so the owner restricts the origin firewall to the WAF's addresses.
How it differs
CSP is a browser-side policy that restricts what scripts and resources a page may load, so it protects visitors from injected content. A WAF sits in front of the server and filters incoming requests, so it protects the app from hostile input. One guards the browser, the other the origin.
Common errors
Believing the WAF makes patching unnecessary. Leaving the origin reachable directly. Running it in log-only mode forever. Turning on every rule and blocking legitimate customers. Never reading the logs.
In practice
Start in log-only mode, review a week of hits, tune exceptions, then block. Lock the origin to accept traffic only from the WAF. Keep patching, since virtual patching rules lag and attackers learn to evade.