Cloudflare WAF Adds Response Blocking: What Free Plans Get
Free Cloudflare plans now let the WAF stop a response after your origin has already sent it. How many rules do you get, and what can’t they undo?

- Cloudflare now correlates requests with responses and can stop a matching response from reaching the caller.
- Free plans get up to three custom response rules; custom response-body conditions are not available yet.
- A detection is not proof of a block, and response blocking cannot roll back an origin-side action.
The response becomes another place to intervene
Cloudflare's October 21 release adds full transaction detection and response rules for traffic proxied through its network. Managed detection currently focuses on confirming exploitation of high-profile vulnerabilities. An application can receive a request before Cloudflare stops the resulting response.
This can prevent sensitive output from reaching the caller. It cannot reverse actions the origin has already performed.
Request-side protections still have a separate job. Under Cloudflare's phase ordering, a terminating action such as Block ends request processing before later phases. Review where a policy acts, rather than treating all blocks as equivalent.
A signature match is evidence, not an enforcement result
The architecture separates observation from action. The existing Attack Signature Detection records confidence, category and reference metadata. A security rule decides how to use that information.
Its documentation explicitly distinguishes a match from a blocked request. That distinction is useful when reviewing the new response controls too: check the policy's action, not just whether a detector found something. Logging and blocking produce different outcomes.
Three rules on Free, with a boundary around body matching
The response-rule announcement specifies these limits:
| Capability | Availability |
|---|---|
| Custom response rules | Up to three on every plan. |
| Actions | Log and Block. |
| Response detection fields in custom policies | Paid customers, with response fields still rolling out across accounts. |
| Custom response-body conditions | Not yet supported. |
Response controls sit at the bottom of Security → Security Rules. The body-condition limitation concerns custom policies; it does not mean managed detection ignores response content.
Count events as events
Security Events helps investigate traffic that a security feature flagged or acted on. Security Analytics covers the broader incoming traffic picture.
One HTTP request can generate several security events. Sampled logs can also omit individual events, so neither a row count nor an empty search proves the number of distinct attacks. Free plans have access to sampled logs rather than the full set of dashboard features.
For an initial policy, use Log to observe matches, then inspect the action and service before deciding where to enforce Block. The operational question is which response was stopped, not how many signatures appeared.
Frequently asked questions
Does a detection mean the request was blocked?
No. Check the rule's action and the recorded outcome.
Can I match arbitrary strings in the response body?
Custom response-body conditions are not supported by this release.
Does response blocking undo an origin-side operation?
No. It stops delivery of the response, not work already completed at the origin.