Cloudflare WAF now reads the response and can block a leak

Cloudflare opened its web application firewall to the response side of an HTTP transaction. A rule can now decide what to do after reading what the origin sent back, so a probe that reaches sensitive data can be blocked on the way out.

The company announced the capability in a post titled "Introducing full transaction detection for Cloudflare WAF". Two new pieces ship together: full transaction detections, which correlate a request with its response and attach the result as metadata, and response custom rules, which can block the origin's response before it reaches the requester. Cloudflare has released both to every plan, including the Free plan, and says managed detections already cover the recently disclosed php2shell vulnerability.

Why Cloudflare moved on the response

The post gives one illustrative example. An attacker sends GET /download?file=../../config/database.ini to an application that lets users download files. A request-only rule can match the directory traversal pattern, but strict matching catches legitimate downloads too, which is why many teams keep the signature loose. Cloudflare writes that the response gives the missing evidence: a traversal pattern in the request plus a response body carrying [database] and password= is "stronger evidence of sensitive data exposure than either signal alone".

The company ties this to AI agents scanning for vulnerabilities. It says these agents are "extremely persistent, adapting payloads using feedback, and chaining vulnerabilities, credentials, and misconfigurations to escalate", and points to this week's php2shell disclosure as the kind of flaw where chasing every variant at the request layer stops being enough.

What ships on which plan

Every customer gets the managed set: a Cloudflare Managed Response Firewall Default ruleset that blocks the response and returns a WAF block page when a signature matches. Free plans get managed response rules focused on high-profile vulnerabilities, the same shape Cloudflare already uses for request-side managed rules. Paying customers can also write custom response rules that combine request fields, response fields, detection outcomes stored in cf.waf.signature.response.*, and up to three custom rules per account with Log and Block actions. Rules on the response body are not yet available.

Cloudflare gives one worked custom rule in the post: block when a path begins with /admin, the x-internal-user header is absent, the response code is 200, and the response is HTML. The intent is to catch an administration page that leaked past an authentication gateway, without blocking ordinary authentication failures or redirects.

Events from the response phase show up in Security Events under Managed Rules or Custom Rules, filterable by rule ID, with the full request context attached so a responder can trace a block back to the detection that fired.

For any team running an application behind Cloudflare, the practical read is that the response phase has become part of the policy surface. A WAF rule that watched requests is now a WAF rule that can watch both halves of the transaction, which closes a hole that was already being probed. The first thing to check is Security Analytics under Security, Security Rules in the dashboard, to see which detections are already firing on your own traffic.

Source

Cloudflare: Introducing full transaction detection for Cloudflare WAF.