WAF

A WAF sits in front of a web application and examines requests before they reach it, comparing them against rules that describe known attack shapes: the signatures of SQL injection, cross-site scripting, path traversal and similar. Requests that match are blocked or challenged. Modern WAFs add rate controls and bot management, and are often bundled with a CDN so the same edge that caches content also filters it. Deployed and tuned well, a WAF reduces the noise of automated attacks and buys time to fix a real flaw. It is a layer at the edge, working on the traffic; it does not change the application underneath.

The dangerous belief is that a WAF makes the application safe. It does not remove the vulnerability; it tries to recognise attacks against it, and recognition is a game the attacker plays too. Signatures are bypassed by encoding, by casing tricks, by splitting a payload, or by using a form of the attack the rules do not model. From the offensive side, a WAF is an obstacle to characterise and route around, not a wall: on our engagements the vulnerable code is still vulnerable, and the WAF often turns a clean finding into a slightly slower one. Worse, a WAF in front of unfixed injection can breed complacency, because the team treats the alert as protection rather than as evidence they are being probed.

We test the application on the assumption that the WAF can be bypassed, because in practice it can. Where a WAF blocks a payload we work to get an equivalent one through, and we report the underlying vulnerability at its true severity regardless, with the WAF noted as a mitigating but non-remediating control. Rate controls are assessed separately, since rate limiting at the edge is genuinely useful against some abuse. This is part of how we test the application behind the WAF.