Introducing full transaction detection for Cloudflare WAF

Cloudflare's WAF now evaluates HTTP requests together with the responses they produce. The addition has two parts: full transaction detections, which look for evidence that an exploit actually succeeded, and response rules, which can block the origin's reply before it reaches the requester. Both are generally available to all customers, Free plans included.

The rationale is that request-only inspection leaves a gap. Frontier models are surfacing vulnerabilities deep in widely used software — the recent php2shell flaw is the example Cloudflare cites — and AI agents hunting for them adapt payloads from feedback and chain weaknesses together. For defenders, a response can be the signal that an attempt worked. The same suspicious input means something different when the origin answers with leaked configuration than when it answers with an error.

Why request-level blocking is not sufficient on its own

Cloudflare WAF already combines managed rules, custom rules and rate limiting, using parameters such as IP address, URL path, headers and request body. Those controls act on requests before they reach the origin, which is the correct place for many threats. The problem is the trade-off when a request alone must decide: broad signatures catch more attacks but also match legitimate traffic and break applications, while narrow signatures avoid false positives at the cost of letting ambiguous traffic through.

The response supplies the missing evidence. Cloudflare can correlate it with the request that caused it, so a detection covers the entire HTTP transaction. A path traversal attempt against a file-download endpoint illustrates it:

GET /download?file=../../config/database.ini

Request inspection can block that traversal outright. But something like this in the reply is what shows the file was actually served:

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

Configuration-like text can appear legitimately in documentation or sample downloads, so neither signal carries much weight by itself. A traversal attempt correlated with configuration-style response content is much stronger evidence of sensitive data exposure. A response rule then substitutes the origin response with a WAF block page and HTTP 403, keeping the data from the attacker and blocking the exploit.

Detections inform, rules decide

The capability extends the always-on detection framework: detections attach metadata to requests and responses, and rules choose what happens next. Because the two are separate, teams can watch detections in their own traffic — which endpoints and signatures are involved — before committing to a policy. As with request-based Attack Signature Detection, detection outcomes land in fields that response custom rules can read or that managed detections can act on. The new response fields mirror the existing request detection fields:

Initial detections concentrate on confirming exploitation of high-profile vulnerabilities. Coverage will widen to other use cases over time, including data exposure and exfiltration signals. The goal is defenses that separate probing from evidence of impact, and that surface exposed data and services even for customers without a security team tuning rules case by case.

Response rules and where to find them

Blocking a response cannot undo anything already executed at the origin, but it does stop the result from reaching the requester in real time. When a blocking rule matches, Cloudflare serves a WAF block page or a custom response in place of the origin's reply. Response-phase controls sit under Security > Security Rules in the dashboard, with managed and custom rules together.

The Cloudflare Managed Response Firewall Default ruleset is the one-click option available to everyone: a signature match blocks the response and returns the standard WAF block page. Its scope can be edited to run detections on only part of an application, for example by excluding or limiting to a specific path.

Paying customers can build more targeted policies by using detection fields in response custom rules:

On free plans, managed detections follow the request-side pattern of focusing on high-profile vulnerabilities, while paid plans get a richer catalog.

Writing a custom response rule

Custom response rules expose full rule logic. One useful case is preventing an admin interface from leaking when the authentication gateway did not flag a request as internal:

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

The rule fires only when an unauthenticated request hits /admin and the origin returns a successful HTML admin page; authentication failures, redirects and unrelated traffic are untouched. Every customer gets up to three custom response rules with Log and Block actions. Field and function availability in the response mirrors what the plan already grants for request custom rules; matching on the response body is not yet supported. Paid plans can also consume detection results through the cf.waf.signature.response.* fields and combine them with a hostname, URL path, source IP or request header to scope protection to a single path or to application context. The response fields are being rolled out to all accounts; customers without access yet were advised to contact their account team.

Investigating matches

Events from managed and custom response rules appear in Security Events, with the full request context and the rule that acted, and detection results are available in Security Analytics for investigation. Request-only and full-transaction rules currently share the same analytics page. Response-rule events are filed under the Managed Rules or Custom Rules service and can be filtered by rule ID in the rule list for that event.

To confirm coverage, open Security > Security Rules in the dashboard. To tailor a policy, review full transaction detections in Security Analytics first, then define a response-phase policy that matches the application.

Full transaction detection is generally available for all zones proxying traffic through Cloudflare.