{"slug": "introducing-full-transaction-detection-for-cloudflare-waf", "title": "Introducing full transaction detection for Cloudflare WAF", "summary": "Cloudflare has made full transaction detection and response rules generally available in its web application firewall (WAF) to all customers, including Free plans. Full transaction detection evaluates each HTTP request alongside its response to identify evidence of exploitation, and response rules can block the origin's response before it reaches the requester; Cloudflare's first managed protections using the capability target the recently disclosed php2shell vulnerability. Cloudflare said the features address AI agents that scan for vulnerabilities persistently, adapting payloads using feedback and chaining vulnerabilities, credentials and permissions.", "body_md": "# Introducing full transaction detection for Cloudflare WAF\n\nToday, 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.\n\nThese 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__](http://blog.cloudflare.com/php-vulnerabilities-waf-protection/) 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.\n\nInspecting 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.\n\nWith 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.\n\nAnd the best part? We are making these new capabilities generally available to all Cloudflare customers, including Free plans.\n\n## Request inspection is not enough\n\n[__Cloudflare WAF__](https://developers.cloudflare.com/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.\n\nFor 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.\n\nThe 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.\n\nAs 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:\n\n```\nGET /download?file=../../config/database.ini\n```\n\nRequest 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:\n\n```\n200 OK\nContent-Type: text/plain\n[database]\nusername=app_service\npassword=EXAMPLE_SECRET\n```\n\n**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.\n\n## Detection and mitigation are separate by design\n\nFull transaction detection extends the [__always-on detection framework__](https://blog.cloudflare.com/attack-signature-detection/) 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.\n\nSeparating 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__](https://developers.cloudflare.com/waf/detections/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.\n\nMirroring the request detection fields, the following new fields are added to our platform:\n\n| Field | Description | \n| cf.waf.signature.response.confidence | Confidence values associated with matching signatures | \n| cf.waf.signature.response.categories | Categories associated with matching signatures | \n| cf.waf.signature.response.ref | Signature reference IDs, up to 10 | \n\nThe 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.\n\nWe will expand coverage over time by supporting other use cases, including detecting data exposure and exfiltration signals. This is important for the Internet beyond any one application: defenses can distinguish probing from evidence of impact, while detection of exposed data and services can reach customers that do not have a dedicated security team tuning every WAF rule.\n\n## Create rules on the response\n\nDetecting evidence of exploitation is most useful if you can act on it in real time. Response custom rules turn full transaction detections into inline protection by blocking a matching origin response before it reaches the requester, although it cannot undo actions already performed at the origin.\n\nSecurity teams can now combine request and response properties with detection results to decide which responses to block. When a blocking rule matches, Cloudflare replaces the origin response with a WAF block page or a custom response.\n\nResponse phase controls are available in the Cloudflare dashboard at the bottom of the *Security > Security Rules* page, with both managed protections and custom rules.\n\nWe have released both managed and custom rules to all plans, including Free plans. Over time, we will follow the same approach we use for request detections, where managed detections for free plans [__focus on high-profile vulnerabilities__](https://blog.cloudflare.com/waf-for-everyone/), while paying customers get a richer catalog of detections.\n\n## Managed detections\n\nAll customers get the protection of the full array of transaction detections through the *Cloudflare Managed Response Firewall Default* ruleset, which is designed for a simple one-click deploy and simplified configurability. When a signature matches, the managed detection will block the response and return a standard WAF block page.\n\nYou can edit the *Cloudflare Managed Response Firewall Default* scope to run detections only on a portion of their applications, for example by excluding or restricting the detection to a specific path. Paying customers can use detection fields in custom response rules to create more tailored policies.\n\n## Custom rules\n\nCustom response rules are designed to give customers full control of the rule logic. A useful rule can stop an administration interface from being exposed when an authentication gateway has not marked the request as internal. For example:\n\n`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\"` \n\nThis blocks only when an unauthenticated request targets `/admin` and the origin actually returns a successful HTML administration page. It does not block ordinary authentication failures, redirects, or non-administration traffic.\n\nAll customers can create up to three custom response rules supporting *Log* and *Block* actions. The fields and functions available in response to custom rules mirrors what your plan gives you access to in [__request custom rules__](https://developers.cloudflare.com/waf/custom-rules/) already. Creating rules on the response body is not yet available.\n\nFollowing the [__Attack Signature Detection__](https://blog.cloudflare.com/attack-signature-detection/) approach, paying customers also have access to the outcome of attack detections through the `cf.waf.signature.response.*`  fields listed above. These fields can be combined with other parameters (such as a hostname, URL path, source IP, request header) to enable protection on a single path, or limit the policy to application-specific context. We are currently rolling out the response fields to all our accounts. If you don’t have access to them yet, please contact your account team.\n\n## Investigating matching requests\n\nWhen a managed or custom response rule logs or blocks a transaction, the event is available in Security Events. This means responders can trace any detection back to the full context of the request and the specific rule that took action.\n\nAt the moment, both request-only rules and full-transaction rules are shown together in the same analytics page. In Security Events, the events generated by response rules are part of the Managed Rules or Custom Rules service. You can filter events belonging to a specific rule ID in the relative rule list section.\n\n## Get started today\n\nFull transaction detection is generally available for all zones proxying traffic through Cloudflare. To verify that you’re protected, go to **Security > Security Rules** in the Cloudflare dashboard. If you want to customize your policy, start by reviewing full transaction detections in Security Analytics, then create the response phase policy that fits your application.", "url": "https://wpnews.pro/news/introducing-full-transaction-detection-for-cloudflare-waf", "canonical_source": "https://blog.cloudflare.com/full-transaction-waf/", "published_at": "2026-10-21 14:10:42+00:00", "updated_at": "2026-10-21 14:13:28.599822+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "artificial-intelligence"], "entities": ["Cloudflare", "Cloudflare WAF", "php2shell", "Security Analytics"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/introducing-full-transaction-detection-for-cloudflare-waf", "markdown": "https://wpnews.pro/news/introducing-full-transaction-detection-for-cloudflare-waf.md", "text": "https://wpnews.pro/news/introducing-full-transaction-detection-for-cloudflare-waf.txt", "jsonld": "https://wpnews.pro/news/introducing-full-transaction-detection-for-cloudflare-waf.jsonld"}}