Cloudflare WAF Can Now Check What Happened After a Suspicious Request

A web application firewall can inspect suspicious traffic before it reaches your website. But a request that looks dangerous does not always prove that an attack worked. The response from your application may provide important context.

Cloudflare has introduced full transaction detections and response rules for its WAF. The new capabilities consider an HTTP request alongside the response from the origin server, then let customers decide whether to block a matching response. Cloudflare’s announcement says both capabilities are generally available to all Cloudflare customers, including Free plans.

For a business owner, the practical question is not only whether your site is being probed. It is whether your security setup can recognize when a suspicious request may have exposed something, and what it can do before that response reaches the requester.

What Cloudflare has added

Cloudflare’s existing WAF controls can inspect incoming requests. Its managed rules cover known attack techniques and vulnerabilities, while custom rules let teams set policies using request details such as an IP address, URL path, headers, and request body.

Full transaction detections add the response to that picture. They correlate the request with what the origin returns, looking for evidence that an attempted exploit may have succeeded. Cloudflare says its first managed protections using this capability address the recently disclosed php2shell vulnerability.

Response rules provide a way to act on a matching response. A rule can replace the origin’s response with a WAF block page or a custom response before the response reaches the requester. This is different from blocking a suspicious request before it reaches the application: the application may already have handled the request.

Cloudflare separates detection from mitigation. Detections attach metadata to requests and responses, while rules use that information to decide what to do. Security teams can review detection results in Security Analytics and choose a policy suited to their application.

Why the response matters

A suspicious request can be ambiguous. A broad request signature might catch an attack attempt, but it can also match legitimate traffic. If a rule blocks that traffic, it may disrupt the application. A narrower rule may avoid that risk but let ambiguous requests reach the server.

The response can provide another signal. Cloudflare illustrates this with a file-download feature. An attacker might change a file parameter to try to reach a private configuration file outside the allowed directory. The request itself may look like an attempt at path traversal. But it does not tell you whether the application rejected it, returned an error, or exposed the file.

If the response contains text characteristic of a private configuration file, that adds evidence that the attempt may have exposed sensitive information. That response content alone could also appear in documentation or example downloads. Combining it with the suspicious request gives a stronger signal than relying on either detail alone.

This is the core idea: the outcome of a request can help distinguish probing from evidence of impact. Cloudflare says it plans to expand coverage over time, including use cases for detecting data exposure and exfiltration signals.

What response rules can and cannot do

A response rule can block a matching origin response before it reaches the requester. In Cloudflare’s example, the WAF replaces the origin response with a block page and HTTP 403. That can prevent sensitive information in the response from being delivered to the person who made the request.

But this does not undo actions that have already happened at the origin. If a request caused a change, triggered another process, or otherwise affected the application before the response was blocked, the response rule cannot reverse that action. Treat it as one layer of protection, not a substitute for secure application design, careful access controls, or investigation of possible compromise.

Cloudflare says customers can combine request and response properties with detection results in custom rules. It also provides managed protections. The new detection fields include confidence values and categories associated with matching signatures. Those details can help teams review why a detection matched before deciding how to respond.

Cloudflare says response-phase controls are available at the bottom of the Security > Security Rules page in its dashboard. Its announcement says managed and custom rules are available on all plans, including Free plans. The company also says free plans will focus on managed detections for high-profile vulnerabilities, while paying customers will get a richer catalog of detections over time.

What this means for your business

If your website or API runs behind Cloudflare, these capabilities may give you another way to identify and respond to suspected exploitation. The feature is especially relevant if your application handles accounts, files, customer records, orders, or other sensitive information. That does not mean every business needs to create a response rule immediately. A poorly understood rule can interfere with legitimate activity or give a false sense of security.

Start by understanding what your application handles and what a successful attack could expose. Review which endpoints accept user input, return files, or provide access to private information. If your site has customer accounts or order management, make sure the systems supporting those journeys are part of your security review. Our website development services include business sites, stores, portals, and platforms; the security needs of each depend on how it is built and used.

Then check whether you can see and interpret your WAF detections. A security tool is most useful when someone can investigate its signals and make a considered decision about blocking. If you do not have a dedicated security team, prioritize understanding the managed protections available to you and getting help with rules you cannot confidently assess.

Build a response plan, not just a rule

Before enabling a response rule, decide what evidence should trigger it and what the rule should do. Consider the consequences of both a missed attack and a mistaken block. Test the logic against the endpoints and responses involved, and review what legitimate content might match the same conditions.

Keep detection and action distinct where possible. First inspect what the detection records in your own traffic. Check the request, response, endpoint, and signature details. Then decide whether a block page or another custom response is appropriate. This matches Cloudflare’s design: detections provide information, and rules determine the action.

Also decide who will review alerts and what they should do if a detection suggests possible exposure. Blocking a response may limit what the requester receives, but it does not establish whether data was accessed or whether the origin took another action. Your process should include investigating the application and addressing any underlying weakness.

A well-built website or portal needs security decisions that fit its actual features. If you are reviewing how your site works and what it needs, our website audit can help you identify areas to examine. For a broader discussion of how design and functionality affect a business site, see our guide to website mistakes that cost customers.

What to do next

1. Check whether your site uses Cloudflare WAF. If it does, review the managed protections and response-phase controls available in your dashboard.
2. Identify sensitive endpoints. List the parts of your site or API that handle private files, accounts, orders, or other information you would not want exposed.
3. Review detection evidence before blocking. Use the available security analytics to understand what matched and what the origin returned.
4. Set a response policy carefully. Decide what evidence justifies blocking, what response users should receive, and who will review the rule’s effects.
5. Investigate the origin as well. A blocked response does not undo actions already performed by the application. Check for underlying weaknesses and address them.

The useful change is not simply that a WAF can inspect more traffic. It is that request and response evidence can be considered together, giving businesses another basis for deciding when to block. Use that capability alongside sound application security and a clear process for investigating what happened.