Cloudflare announced full-transaction detection and response rules for its WAF. These correlate an HTTP request with the server’s response and can block a matching response before it reaches the requester. Cloudflare official announcement
Suspicious input and a response exposing sensitive information are different signals. Correlating them can improve detection, but blocking the response cannot reverse file changes or other operations already performed by the application.
On this page
Request and response together provide a different signal
A web application firewall examines HTTP traffic in front of an application. Inspecting a request can identify suspicious input, while the response supplies information about what the server returned. An authentication failure and a response containing sensitive material deserve different investigations even when the original request looks similar. Correlation adds evidence for making that distinction.
For a management path that should not be public, distinguish a redirect to login from a successful response containing administrative content. Status alone is insufficient: some applications return error pages with a 200 code. Review the response type and the endpoint’s real behavior before treating a matching traffic pattern as confirmed exposure.
Detection and blocking occur at different decision points
Detection records suspicious traffic properties, while blocking applies a policy to stop delivery. A response-phase block can prevent the requester from receiving the origin’s output even though the application has already processed the request. File writes or database changes completed at the origin are not rolled back by replacing the outgoing response. This distinction matters when interpreting a blocked event.
Investigate origin-side handling and data changes after a response block. Request identifiers and normalized timestamps help connect WAF events with application logs. Retaining only the block page shown to the client leaves the server-side outcome unexplained. Preserve evidence from both the edge control and the application so that containment is not mistaken for proof that nothing happened.
Learn normal responses before broadening the rule
For a hypothetical rollout, prepare representative public pages, failed logins, legitimate administrative access, and downloads. Record request and response characteristics, then review detections and false positives on a limited set of paths. Avoid widely copying sensitive production responses into test materials; retain only necessary evidence in an appropriately restricted location.
After enabling a rule, compare blocking activity with failures affecting legitimate requests. Define which rule can be rolled back and who owns the underlying application fix. A WAF can reduce exposure to recognized attacks without replacing patching or authorization design. Verify the rule scope and available fields against the official guidance for the account actually being used.
Introduce response rules gradually
- Establish normal status codes, headers, and important response types.
- Review detection and false positives on a limited path.
- Connect WAF events with origin logs at the request level.
The announcement includes availability across plans, but detailed detection and rule capabilities vary. Check both entitlement and active configuration in your account.
Announcement reference date: 2026-10-21 · Checked: October 24, 2026
