Today, we are expanding our web application firewall (WAF) by adding two new capabilities: full transaction detections and response rules. Full transaction detections evaluate each HTTP request alongside its response to identify evidence of exploitation. It helps answer both "Does this request look malicious?"
and "What happened when the application handled it?" Response rules can then block the origin’s response before it reaches the requester. These are valuable protections because the latest frontier models are uncovering vulnerabilities buried deep in widely used software, giving defenders clarity on what to fix — and attackers new paths to exploit.
The recent php2shell vulnerability shows the stakes: a flaw in a common software component can put applications across the Internet at risk. AI agents scanning for vulnerabilities can be extremely persistent, adapting payloads using feedback, and chaining vulnerabilities, credentials, and permissions. An application's response can reveal whether an attempt worked and give an attacker information that helps them go deeper.
Inspecting incoming requests remains essential for stopping recognizable attacks before they reach an application. But some threats become clear only when the request is considered alongside what the origin returns. A suspicious input followed by a response exposing sensitive information tells a different story from the same input followed by a rejection or an error.
With these new capabilities, customers can use Cloudflare-managed protections or build their own policies combining request and response properties. This extends our always-on application security framework, with detection results available in Security Analytics to support investigation. Our first managed protections using this capability address the recently disclosed php2shell vulnerability.
And the best part? We are making these new capabilities generally available to all Cloudflare customers, including Free plans. Request inspection is not enough Cloudflare WAF protects websites and APIs with managed rules, custom rules, and rate limiting.
Managed rules provide protection for known attack techniques and vulnerabilities while custom rules let teams create their own policies using parameters such as an IP address, URL path, headers, and request body. These controls operate at the request level to stop exploits or unwanted traffic from reaching the origin. For many threats, this is the right place to act.
However, treating every suspicious request as a confirmed exploit creates a difficult choice. Broad request signatures can catch more potential attacks, but they can also show “false positives”, such as matching legitimate traffic — which then breaks the applications. Deploying only rules that do not trigger false positives reduces that risk, but can leave more room for more ambiguous traffic to reach the server.
The response provides the missing evidence. Cloudflare can now correlate it with the request that produced it, so detections can account for the outcome of the entire HTTP transaction. As an illustrative example, consider an application that lets users download files.
An attacker manipulates the file parameter to request a private configuration file outside the permitted directory: GET /download? file=.. /..
/config/database. ini Request inspection can recognize this path traversal attempt and block it before it reaches the application. The request alone, however, cannot establish whether the application would expose the file.
It might reject the request, ignore the traversal, or return an error. If the request reaches the origin, a response like this provides additional evidence: 200 OK Content-Type: text/plain [database] username=app_service password=EXAMPLE_SECRET Full transaction detection provides a missing piece: it can correlate the attempted file access with response content characteristic of a private configuration file.
Configuration-like text can legitimately appear in documentation or example downloads; combining it with a traversal attempt provides stronger evidence of sensitive data exposure than either signal alone. A response rule can then replace the origin response with a Cloudflare WAF block page and HTTP 403 before it reaches the requester, effectively blocking the exploit by preventing sensitive information from reaching the attacker.
Detection and mitigation are separate by design Full transaction detection extends the always-on detection framework we introduced earlier this year. Detections analyze traffic and attach metadata to the request and response, rules then decide what to do with those results. Separating those jobs gives customers visibility before they design a policy.
Security teams can inspect detections in their own traffic, understand which endpoints and signatures are involved, and choose the response that fits their application. Similar to the approach for the request-based Attack Signature Detection , the outcome of the detections are stored in fields that can be accessed in the response custom rules or used in managed detections to block traffic.
Mirroring the request detection fields, the following new fields are added to our platform: Field Description cf. waf. signature.
response. confidence Confidence values associated with matching signatures cf. waf.
signature. response. categories Categories associated with matching signatures cf.
waf. signature. response.
ref Signature reference IDs, up to 10 The first full transaction detections focus on exploit confirmation for high profile vulnerability. It correlates suspicious input with response signals that indicate an exploit may have succeeded. We will expand coverage over time by supporting other use cases, including detecting data exposure and exfiltration signals.
Originally published at blog.cloudflare.com
