- Cloudflare says its web application firewall can now pair each request with the server's reply and block the reply if it shows an exploit worked. All plans get it.
- A request shows intent, while a reply shows impact. Cloudflare says a response rule cannot undo what the origin server already did.
- Teams should check what is switched on, review detections before enforcing them, and test any response rule against normal traffic.
A web request is a claim. The response is the proof. Until now, Cloudflare's WAF judged requests by how they look. Cloudflare says that forces a trade-off between blocking too much and missing too much. Its new feature, announced October 21, lets the firewall also judge by what the server sent back.
What Cloudflare announced
Cloudflare is adding two tools to its web application firewall (WAF). The first is full transaction detection. It reads a request together with the reply the application gave, and looks for signs of a successful attack. The second is the response rule. It can swap that reply for a block page and an HTTP 403 error before the requester sees it.
Cloudflare says both are generally available to all customers, including Free plans. Its first managed protections cover a recently disclosed flaw it calls php2shell. The post does not give a CVE ID for it.
The trade-off this addresses
Cloudflare describes a hard choice. Broad rules catch more attacks. They can also match honest traffic and break the application. Narrow rules avoid that, but let more doubtful traffic reach the server.
Picture a security engineer who switched off a noisy rule because it blocked real customers. The attack pattern kept arriving, and nothing was watching for it. The reply gives that engineer a second signal, so the rule no longer has to guess.
How it works
Cloudflare's example is a page that lets users download files. An attacker edits the file name in the request. The aim is to fetch a private configuration file outside the permitted folder. This trick is called path traversal.
The request alone cannot show whether the application obeyed. It might refuse, ignore the trick, or return an error. Now suppose the reply holds text typical of a private configuration file. That changes the picture. Such text can also appear in documentation. So Cloudflare treats the attempt and the content together as stronger evidence than either one.
Finding and acting are two separate steps. A detection tags the request and the reply with results, such as confidence values and categories for matching signatures. A policy then chooses the action, and Cloudflare manages some of these for you. Cloudflare says this split lets teams study the findings in their own traffic before they enforce anything.
What the feature cannot do
This is the point executives should hold onto. A response rule acts after the request has reached the origin server. Cloudflare says it cannot undo actions already done there. The attacker is kept from seeing the result. The application still did the work.
Cloudflare lists other limits. Rules on the reply body are not yet available. Each account can write up to three of its own response rules, and each one can either log the event or block the reply.
The detection fields for response rules are meant for paying customers' custom rules. Cloudflare says it is still rolling those fields out across accounts. If you pay for a plan and cannot see them yet, ask your account team.
The first detections confirm exploits of high-profile flaws. Cloudflare says it plans to add detection of data exposure later.
Why Cloudflare says it matters now
Cloudflare argues that the latest frontier AI models are finding flaws buried in widely used software. It says AI agents that scan for flaws can be persistent. They adjust payloads using feedback and chain together flaws, credentials and permissions. In that view, each reply is a hint that helps an attacker go deeper.
That is Cloudflare's claim, and the post offers no measurements for it. The defensive logic holds either way. If a probing tool learns from every reply, then controlling what replies reveal is a sound control.
What to ask your team
First, ask whether the response-phase protection is on. Cloudflare says all customers get it through its Managed Response Firewall Default ruleset. A matching reply is blocked and a standard block page is returned. Confirm this covers your zones.
Second, ask who reviews detections in Security Analytics before anything is enforced. Cloudflare recommends that order. Ask whether some paths should be excluded because honest content there looks like an exploit result, such as documentation downloads.
Third, ask what happens at the origin when a blocked exploit still ran. Patching remains the fix. A rule that hides a successful exploit could also hide the sign that you need to patch. Check that blocked events reach your investigators through Security Events.
Finally, test custom rules against normal traffic. Cloudflare's own example blocks only when an unauthenticated request to an admin path gets a successful HTML page back. Narrow rules like that are easier to trust.
A request shows what an attacker wanted. A response shows what they got. Watching both gives a team better evidence, but only patching removes the flaw.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
