Cloudflare WAF Full Transaction Detection Checks What the Origin Returns

The interesting part of this release is that WAF decisions no longer have to rest on the request alone. Cloudflare's new full transaction detections evaluate each HTTP request together with the response the origin sends back, and response rules can block that response before it reaches the client. The capability is generally available to all customers, including Free plans, and it's the first time Cloudflare WAF policies can key on what the application actually did.

Timing matters here. Frontier models are getting better at finding vulnerabilities buried in widely used software, which helps defenders prioritize fixes but also gives attackers new paths. Cloudflare points to the recent php2shell vulnerability as an example of how a flaw in a common component can put many applications at risk at once. The attacker side is getting more persistent, too. Automated agents can scan relentlessly, adapt payloads based on feedback, and chain vulnerabilities with credentials and permissions. An application's response is often the feedback they're looking for, because it tells them whether an attempt worked and what to try next.

Where request inspection runs out

Cloudflare WAF already protects websites and APIs with managed rules, custom rules, and rate limiting. Managed rules cover known attack techniques and vulnerabilities, while custom rules let teams match on parameters such as IP address, URL path, headers, and request body. All of these operate at the request level, stopping exploits or unwanted traffic before they reach the origin.

That works well for recognizable attacks, but it forces a tradeoff. Broad signatures catch more potential attacks, yet they can also match legitimate traffic and produce false positives that break applications. Restricting deployment to rules that never false-positive leaves more ambiguous traffic reaching the server. Request data alone can't settle the question.

Consider a file download endpoint where an attacker manipulates the file parameter to reach a configuration file outside the permitted directory:

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

Request inspection can recognize that path traversal pattern and block it. But the request alone doesn't reveal whether the application would have served the file. It might reject the request, ignore the traversal, or return an error. If the request does reach the origin, the response may contain the answer:

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

Full transaction detection correlates the traversal attempt with response content that looks like a private configuration file. Configuration-style text can legitimately appear in documentation or example downloads, so neither signal is conclusive alone. Together they make a much stronger case for sensitive data exposure. A response rule can then replace the origin response with a Cloudflare WAF block page and HTTP 403, so the secret never reaches the requester.

Detection and mitigation are deliberately separate

Full transaction detection extends the always-on detection framework Cloudflare introduced earlier this year. Detections analyze traffic and attach metadata to the request and response. Rules then decide what to do with that metadata. Keeping those two jobs apart means a security team can inspect what's being detected in its own traffic, see which endpoints and signatures are involved, and only then write a policy that fits the application.

The approach mirrors request-side Attack Signature Detection. Detection outcomes land in fields that custom rules can read, and managed detections can use them to block traffic. For response-side detections, the new fields are:

The first full transaction detections target exploit confirmation for high-profile vulnerabilities. They look for suspicious input paired with response signals suggesting the exploit may have worked. Cloudflare says it will expand coverage to other use cases, including detecting data exposure and exfiltration signals. That's the more interesting long-term direction. It lets defenses distinguish probing from evidence of actual impact, and it can reach customers who don't have a dedicated security team tuning every WAF rule.

Response rules and their limits

Detecting exploitation only helps if you can act on it in real time. Response custom rules do that by blocking a matching origin response before it reaches the requester. They have one hard limit: they can't undo actions the origin has already performed. If a request triggered a write or a state change before the response was blocked, that change stays. Teams should plan for that when they choose which endpoints to protect.

Response phase controls sit at the bottom of the Security > Security Rules page in the Cloudflare dashboard, alongside managed protections and custom rules. When a blocking rule matches, Cloudflare replaces the origin response with a WAF block page or a custom response.

For custom response rules, the logic can combine request and response properties. Here's a rule that prevents an admin interface from being exposed when an upstream authentication gateway hasn't marked the 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"

This blocks only when an unauthenticated request targets /admin and the origin actually returns a successful HTML page. Normal authentication failures, redirects, and unrelated traffic pass through. That precision is what makes response rules practical: the condition describes the failure you care about, not just the path.

Current constraints are worth knowing before you design a policy. Every customer can create up to three custom response rules, with Log and Block actions. The fields and functions available in response custom rules mirror what your plan already offers in request custom rules. Rules that inspect the response body aren't available yet. Paying customers can also use the cf.waf.signature.response.* fields, which are rolling out to all accounts. If you don't see them yet, Cloudflare says to contact your account team.

Managed detections and the free tier

Every customer gets the full set of transaction detections through the Cloudflare Managed Response Firewall Default ruleset, which is built for one-click deployment. When a signature matches, the managed detection blocks the response and returns the standard WAF block page. You can narrow the ruleset's scope to run detections on only part of an application, for example by excluding a path or restricting detection to a specific one. Paying customers can go further by writing custom response rules that use detection fields.

On tiering, Cloudflare plans to follow the pattern it uses for request detections. Managed detections on Free plans will focus on high-profile vulnerabilities, while paid plans get a richer detection catalog. That's a reasonable split, though it means free-tier protection will be narrower by design.

Reading the results

When a managed or custom response rule logs or blocks a transaction, the event appears in Security Events. Responders can trace a detection back to the full request context and the specific rule that acted. Request-only rules and full-transaction rules appear together in the same analytics view. Events from response rules sit under the Managed Rules or Custom Rules service, and you can filter by rule ID in the relevant rule list.

Where to start

Full transaction detection is generally available for all zones proxying traffic through Cloudflare. To confirm your protection is active, check Security > Security Rules in the dashboard. If you want to tune the policy, begin in Security Analytics by reviewing which full transaction detections fire on your traffic. Then build the response-phase policy around the endpoints that matter most.

My read is that the first thing to watch is false-positive behavior on response rules, since matching on response content is more context-dependent than matching on request patterns. The second is whether body-level rules and broader data exposure detection arrive, because that's where response-phase protection would move from confirming known exploits to catching impact more generally.