Cloudflare WAF can now inspect the response, not just the request
Full transaction detection lets Cloudflare correlate a request with what the origin sent back, so response rules can block a leak or a successful exploit before it reaches the attacker.
Cloudflare’s WAF has, until now, only ever judged the request. On 21 October it shipped full transaction detection, which correlates a request with the origin’s response in the same HTTP transaction, so it can tell the difference between an attack that was merely attempted and one that actually worked.
The example Cloudflare gives: a path traversal attempt is only proof of a breach once the response also contains database credentials. Neither signal alone is enough. New fields, cf.waf.signature.response.confidence, cf.waf.signature.response.categories and cf.waf.signature.response.ref, expose that correlation to rules. Response rules can then block the origin’s response itself, swapping it for a WAF block page before it reaches whoever sent the request. The capability is generally available to every plan, including Free, though paying customers get a richer detection catalogue and the ability to write custom rules against it.
The first managed protection built on this is aimed at the php2shell PHP vulnerabilities, letting Cloudflare catch cases where an exploit attempt actually produced a working response, not just a suspicious request.
Why it matters: request-only inspection misses successful data exposure and misconfigurations that only show up in what your app sends back. If you run traffic through Cloudflare’s WAF, this is a new axis to write rules on, not just “does this request look bad” but “did the response prove it worked”.
The caveat: the deeper detection catalogue and custom response rules are tied to paid plans; Free plans get the managed protections Cloudflare ships, not the ability to author your own.