In a significant upgrade to its core security infrastructure, Cloudflare has announced the expansion of its web application firewall (WAF) to include two major capabilities: full transaction detections and response rules. This new architecture allows the security platform to evaluate incoming HTTP requests alongside the corresponding origin responses, providing a holistic view of web traffic. By assessing both the initial request and the resulting server output, Cloudflare’s WAF can definitively answer whether a request looks malicious and, crucially, what actually happened when the application handled it. Furthermore, the newly introduced response rules enable the system to intercept and block an origin’s response before it ever reaches the requester, adding a powerful layer of inline defense.
The timing of this security enhancement reflects a shifting threat landscape driven by the rapid evolution of artificial intelligence. Modern frontier models are increasingly capable of uncovering deep-seated vulnerabilities hidden within widely used software components. While these AI advancements help defenders gain clarity on what code needs patching, they simultaneously provide malicious actors and automated AI agents with sophisticated new pathways for exploitation. A recent example is the php2shell vulnerability, which demonstrated how a single flaw in a common software component can instantly put applications across the entire Internet at risk. Autonomous AI agents are particularly dangerous because they can scan for vulnerabilities with relentless persistence, adapting their payloads dynamically using real-time feedback and
successfully chaining multiple vulnerabilities, stolen credentials, and permission flaws together. In this environment, an application’s response can inadvertently confirm whether an attack attempt was successful, feeding vital information back to an attacker and helping them penetrate deeper into the system.
Traditionally, web application firewalls have relied heavily on inspecting incoming requests to intercept recognizable attack signatures before they can ever reach an underlying application. While this practice remains an essential first line of defense, security engineers have long recognized that certain threats only become fully apparent when a request is evaluated in the direct context of what the origin server returns. For instance, a suspicious input string followed by a response that exposes sensitive corporate or user information tells an entirely different security story than the exact same input followed by an immediate rejection or an error code. By correlating requests with their corresponding outputs, Cloudflare’s new system bridges this critical visibility gap. Customers can now leverage Cloudflare-managed protections or build custom security policies that seamlessly combine both request and response properties, with all detection results feeding directly into Security Analytics for comprehensive post-incident investigation. The first managed protections utilizing this new capability are tailored specifically to address the recently disclosed php2shell vulnerability, and Cloudflare has made these advanced features generally available to all customers, including those on Free plans.
Request Inspection Is Not Enough
Cloudflare’s WAF has long protected websites and APIs through a combination of managed rules, custom rules, and rate-limiting features. Managed rules defend against known attack techniques and vulnerabilities, while custom rules empower security teams to craft bespoke policies using parameters such as IP addresses, specific URL paths, custom headers, and the request body. Operating primarily at the request level, these traditional controls successfully stop many exploits and block unwanted traffic before it reaches an origin server.
For a broad range of common threats, request-level mitigation remains the ideal approach. However, treating every single suspicious request as a confirmed exploit presents security administrators with a difficult operational dilemma. Broad request signatures can catch a higher volume of potential attacks, but they frequently trigger false positives—erroneously flagging legitimate traffic and potentially breaking application functionality in the process. Conversely, deploying only conservative rules that avoid false positives minimizes disruption, but leaves the door open for more ambiguous or novel traffic to reach the server unhindered.
The missing piece of the security puzzle is the origin response itself. By correlating the response with the specific request that produced it, Cloudflare enables detections that account for the definitive outcome of the entire HTTP transaction. To illustrate this concept, consider a common scenario involving an application that permits users to download files. An attacker might manipulate the file parameter within a URL query to request a sensitive configuration file located outside the permitted directory structure, issuing a request such as a directory traversal attempt targeting a database initialization file.
Traditional request inspection can certainly recognize this path traversal pattern and attempt to block it prior to application processing. However, a request alone cannot definitively establish whether the underlying application would actually yield to the attack by exposing the file. The application might intelligently reject the request, ignore the traversal characters entirely, or simply return an application error. If the request does manage to reach the origin and the server responds with a 200 OK status containing database credentials, service usernames, and example secrets, the risk shifts from a theoretical probe to an actual data exposure event.
Full transaction detection provides the missing analytical context by correlating the attempted file access with response content characteristic of a private configuration file. Because configuration-like text can sometimes appear legitimately in documentation or example downloads, combining the text with a traversal attempt provides far stronger, more accurate evidence of sensitive data exposure than either signal could offer in isolation. Once flagged, a response rule can automatically replace the origin’s response with a standard Cloudflare WAF block page and an HTTP 403 status code before the data reaches the requester, effectively neutralizing the exploit by keeping sensitive information out of the attacker’s hands.
Detection and Mitigation Are Separate by Design
This latest full transaction detection capability builds directly upon the always-on detection framework that Cloudflare introduced earlier this year. Under this architecture, detections analyze passing traffic and attach descriptive metadata to both the request and the response, while independent rules subsequently dictate the appropriate mitigation action. Separating the detection phase from the mitigation phase gives security teams vital visibility before they commit to enforcing a strict policy. Security professionals can inspect detections live within their own traffic, understand precisely which endpoints and signatures are involved, and choose a response strategy tailored to the specific needs of their application.
Mirroring the design of request-based attack signature detection, the outcomes of full transaction detections are stored in dedicated platform fields. These include confidence values associated with matching signatures, specific categories tied to those signatures, and signature reference IDs. The initial rollout of full transaction detections focuses heavily on exploit confirmation for high-profile vulnerabilities, effectively correlating suspicious input with response signals that indicate a successful exploit. Over time, Cloudflare plans to expand this coverage to encompass broader use cases, including the detection of data exposure and exfiltration signals. This ongoing expansion is particularly beneficial for organizations lacking dedicated security teams to manually tune every individual WAF rule, as it ensures baseline defenses can accurately distinguish harmless probing from tangible security impact.
Create Rules on the Response
Detecting evidence of exploitation is only valuable if security systems can act upon it in real time. Response custom rules transform full transaction detections into inline protections by intercepting a matching origin response before it reaches the requester, though they cannot undo server-side actions that have already occurred at the origin. Security teams can now combine request and response properties alongside detection results to make granular decisions about which responses to block, replacing offending origin data with a standard WAF block page or a custom response message.
These response phase controls are accessible directly within the Cloudflare dashboard under the security rules interface, encompassing both managed protections and custom rules. All customer tiers, including Free plans, have access to these response rules. For free accounts, managed detections will continue to focus primarily on high-profile vulnerabilities, while paying customers receive access to a much deeper and broader catalog of detections.
Managed Detections and Custom Rules
All Cloudflare customers automatically benefit from the full array of transaction detections through the Managed Response Firewall Default ruleset, which is built for simple, one-click deployment and straightforward configurability. When a signature matches, the managed detection automatically blocks the response and returns a standard WAF block page. Administrators retain the flexibility to edit the scope of this default ruleset, running detections only on specific portions of their applications or restricting them to sensitive URL paths. Paying customers can additionally leverage detection fields in custom response rules to build highly targeted, application-specific security policies.
Custom response rules give organizations complete control over complex rule logic. For instance, a security team can construct a rule designed to prevent an administrative interface from being exposed when an authentication gateway has failed to properly mark a request as internal. By evaluating criteria such as whether a URI path starts with a specific administrative directory, whether an internal user header is absent, and whether the origin actually returns a successful 200 OK HTML page, the system can block unauthorized access precisely without disrupting ordinary authentication failures, normal redirects, or unrelated traffic.
All customers can create up to three custom response rules supporting log and block actions, with available fields and functions mirroring those already provided in request custom rules. For paying customers, the newly introduced response signature fields can be combined with parameters like hostnames, URL paths, source IP addresses, and request headers to enforce protection on single paths or limit policies to specific application contexts.
Investigating Matching Requests
When a managed or custom response rule successfully logs or blocks a transaction, the corresponding event is recorded and made available within Security Events. This integration allows incident responders to trace any detection back to the full context of the originating request and the precise rule that took enforcement action. Request-only rules and full-transaction rules appear together within the same analytics interface, where events generated by response rules are categorized under managed or custom rules, allowing administrators to easily filter events by specific rule IDs.
Full transaction detection is now generally available for all zones proxying traffic through Cloudflare. Administrators can verify their protection status within the security configuration dashboard, review active detections via Security Analytics, and begin crafting response-phase policies tailored to their application requirements.
