Cloudflare's web application firewall now incorporates full transaction detection, enabling correlation between an HTTP request and its corresponding response. This capability assists all clientele in identifying successful exploits, data exposures, and risky misconfigurations that inspection based solely on requests might overlook.
The expansion introduces two new features: full transaction detections and response rules. Full transaction detections evaluate each HTTP request in conjunction with its response to pinpoint evidence of exploitation. This addresses both the query, "Does this request look malicious?" and the outcome, "What happened when the application handled it?"
Response rules then permit blocking the origin’s response before it reaches the requesting party. These protections are significant because emerging frontier models are revealing vulnerabilities within widely deployed software, offering defenders clarity on required fixes and presenting attackers new avenues for exploitation.
The recent php2shell vulnerability exemplifies the gravity of this situation: a defect in a common software component can endanger applications across the Internet. Furthermore, AI agents scanning for vulnerabilities exhibit high persistence, adapting payloads based on feedback and chaining credentials, permissions, and vulnerabilities.
While inspecting incoming requests remains crucial for stopping recognizable attacks before they reach an application, certain threats only become evident when the request is considered alongside the origin's return data. A suspicious input followed by a response exposing sensitive information conveys a different narrative than the same input resulting in an error or rejection.
With these new features, customers can utilize Cloudflare-managed protections or construct their own policies integrating request and response characteristics. This extends the always-on application security framework, with detection findings residing in Security Analytics to aid investigation. The initial managed protections leveraging this feature target the recently disclosed php2shell vulnerability.
This functionality is now generally available to every Cloudflare customer, including those on Free plans. Cloudflare WAF safeguards websites and APIs using managed rules, custom rules, and rate limiting. Managed rules guard against known attack techniques and vulnerabilities, while custom rules permit teams to define their own policies using parameters such as IP address, URL path, headers, and request body.
However, treating every suspicious request as a confirmed exploit presents a difficult operational trade-off. Broad request signatures can catch more potential attacks but risk generating "false positives," which can disrupt legitimate application traffic. Deploying only non-false-positive rules mitigates this risk but may allow more ambiguous traffic to reach the server. The response data provides the necessary corroborating evidence.
For instance, if an attacker attempts path traversal via a file parameter, request inspection may flag the attempt. Yet, the request alone cannot confirm if the application would disclose the file. If the request reaches the origin, a response like "200 OK Content-Type: text/plain [database] username=app_service password=EXAMPLE_SECRET" offers critical additional evidence. Full transaction detection correlates the attempted access with response content characteristic of a private configuration file.
This mechanism allows a response rule to substitute the origin response with a Cloudflare WAF block page and HTTP 403 before it reaches the requester, effectively neutralizing the exploit by preventing sensitive information from reaching the adversary.
The separation of detection and mitigation is intentional. Detections analyze traffic and affix metadata to both the request and response, while rules subsequently determine the appropriate action based on those results. This separation grants customers visibility before they finalize policy design.
This development reflects a broader industry trend where defensive mechanisms must move beyond simple ingress filtering to analyze the complete interaction lifecycle between an attacker and the protected service. The ability to distinguish probing from evidence of actual impact is vital for organizations of all sizes.
Response custom rules transform full transaction detections into inline defense by blocking a matching origin response prior to its delivery to the requester, though this action cannot reverse any activity already completed at the origin. Security teams can now integrate request and response properties with detection outcomes to decide which responses to block.
Managed detections provide all customers with the protection of the full array of transaction detections via the Cloudflare Managed Response Firewall Default ruleset, which offers simple deployment and configuration. When a signature matches, this managed detection blocks the response and returns a standard WAF block page.
Custom response rules afford customers complete control over rule logic. An example illustrates this: "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 rule blocks only when an unauthenticated request targets "/admin" and the origin returns a successful HTML administration page.
The outcome of attack detections is stored in fields such as cf.waf.signature.response.confidence, cf.waf.signature.response.categories, and cf.waf.signature.response.ref, which can be combined with other parameters to enable protection on a specific path.
When a managed or custom response rule logs or blocks a transaction, the event is recorded in Security Events, allowing responders to trace any detection back to the full context of the request and the specific rule that enacted the action.
Full transaction detection is generally available for all zones routing traffic through Cloudflare.
