Cloudflare has introduced Full Transaction Detection for its web application firewall. The WAF now looks not only at what arrives at a site but also at what the site sends back.

The idea is simple: if a request looked suspicious and the response clearly shows signs of a leak, that response can be swapped for a block page before it reaches the attacker.

Why filtering requests alone falls short

Classic WAF rules parse the URL, headers and body of a request and try to stop an attack before the application handles it. The catch is that "dangerous" characters show up in ordinary traffic all the time. Strict rules cause false blocks, lenient ones let real exploitation through.

The server's response helps tell a failed attempt from a real breach. Cloudflare gives the example of a path traversal through a file download parameter: the request alone proves nothing, but a configuration file in the response clearly signals a leak. In that case the WAF can return a 403 error instead.

How it works

Detection and response are separated. The system writes the check result and a confidence level into dedicated fields, and managed or custom rules then decide whether the response goes through. Detections show up in Security Analytics and Security Events.

Rules can be limited to specific site paths. That lowers the risk of breaking legitimate pages that return similar data by design.

Commentary

Response inspection does not replace updates and careful code, but it offers one more chance when a vulnerability is found before the patch. For PHP and CMS sites, where holes appear regularly, this layer is especially useful, and path-level tuning helps avoid false blocks. Details in the SecurityLab article.