Always-on detections: eliminating the WAF “log versus block” trade-off

Detecting threats without the log-versus-block choice

Web Application Firewalls have traditionally forced security teams into an uncomfortable position: run rules in logging mode to avoid false positives, or enable blocking and accept the risk of disrupting legitimate traffic. The manual tuning process that follows a new application deployment is slow, and when a rule blocks a request, evaluation stops — hiding how other signatures would have judged that same traffic.

Attack Signature Detection, now in Early Access, separates detection from mitigation entirely. Every request is inspected for malicious payloads, and the metadata from those inspections is attached before any action is taken. Traffic is analyzed continuously, so you can see exactly which signatures fire and why. Mitigation policies can then be built from observed traffic patterns rather than guesswork.

The same framework extends beyond request-only analysis. Full-Transaction Detection, currently under development, correlates the entire HTTP transaction — request and response — to reduce false positives and identify threats that only appear in the response, such as reflective SQL injection and data exfiltration patterns.

An always-on detection framework

The architecture separates detection from the rules that act on it. For customers who opt in, Attack Signature Detection is enabled by default as soon as traffic is proxied. All signatures execute on every request, with results surfacing immediately in Security Analytics.

Detection results enrich analytics and are added to the request as a new field, which security rules can reference when building custom policies. Existing Bot Score and Attack Score detections already follow this model. Attack Signature Detection applies the same approach to Managed Rules coverage.

This design does not add latency during onboarding. If no blocking rule references a detection, the detection runs after the request has been forwarded to the origin server. Once a blocking rule is created, the detection moves in-line with the request, and any latency impact depends on the application's traffic profile.

How signatures differ from managed rules

The Cloudflare Managed Ruleset contains more than 700 active rules developed by the analyst team, covering SQL injection (SQLi), Cross Site Scripting (XSS), Remote Code Execution (RCE), and specific CVEs. New rules ship weekly, with emergency releases for high-profile vulnerabilities.

The new detections — also called signature rules or signatures — use the same heuristics as Managed Rules but do not apply actions to traffic directly. Each signature has a unique Ref ID (analogous to a Rule ID) and is tagged with a category and a confidence level. Categories describe the targeted attack vector, such as SQLi, XSS, RCE, or a specific CVE. Confidence indicates the likelihood of a false positive; a signature has one confidence level but can carry multiple categories.

Working with detections in Security Analytics

Security Analytics provides the data layer for understanding how signatures interact with live traffic. Once a new application is proxied, the dashboard populates with aggregated matches grouped by signature and category. Reviewing top statistics — whether requests were blocked, served from cache, or allowed to reach the origin — helps confirm that malicious traffic is being stopped. If requests reach the origin, rules can be created quickly to close the gap.

Analytics also exposes attack patterns, such as the most frequently triggered CVEs over time. Filters and the Attack Analysis tool can focus on specific endpoints — for example, traffic targeting /api/ or the POST /_next/ Node.js path associated with React2Shell payloads.

False positives are a primary use case for the analytics workflow. An application that accepts rich HTML content, such as a CMS or support ticketing system, may legitimately trigger generic XSS signatures. In such cases, a scoped exception can be applied to the affected endpoint only, leaving protection enabled elsewhere.

This workflow is particularly valuable for evaluating medium-confidence signatures, which balance aggressive protection against false-positive risk. Testing signatures against historical traffic in "what-if" scenarios helps determine whether a rule can be deployed broadly or needs to be limited to specific URLs or request types. Signatures with low match rates against historical traffic are generally safer to enable in block mode.

Building rules from detection data

Once confidence is established, custom rules can be created from the detection metadata. A rule blocking requests that match high-confidence signatures is equivalent to the Managed Ruleset's default deployment. Blocking both High and Medium confidence tags matches the behavior of enabling all Managed Ruleset rules. Alternatively, separate rules can apply different actions — Block for High confidence, Challenge for Medium confidence.

Rules can also target specific categories or Ref IDs. Category-based rules allow granular policies — blocking a particular CVE or attack vector — combined with any existing HTTP request attributes. Ref ID-based rules are useful for exceptions that manage false positives; the rule builder lets you browse available signatures directly.

Managed Ruleset availability

The classic Managed Ruleset remains available to all customers. Once Attack Signature Detection reaches general availability, customers can choose between deployment models. New detections are released simultaneously across both the Managed Ruleset and Attack Signature Detection.

Judging Attacks by Their Outcomes

Request-only inspection assumes the intent of a request is enough to judge it malicious. But a request is only half the story. The response reveals whether an exploit attempt actually succeeded, whether sensitive data left the origin, or whether a misconfiguration is publicly accessible.

Full-Transaction Detection pairs request and response metadata into a single event. This approach cuts through the noise of request-only systems and surfaces exploits they would miss entirely.

Consider a common SQL injection attempt:

GET /user?id=1' UNION SELECT username, password FROM users--

A traditional WAF sees the UNION SELECT signature and blocks the request. But what if the target application isn't vulnerable? A security researcher testing their own site might trigger the same signature, creating a false positive.

With Full-Transaction Detection, the system holds the SQLi signature and waits for the origin's response. A 500 Internal Server Error or 404 response suggests the exploit didn't land. A 200 OK response body carrying sensitive data—such as a list of usernames matching a data signature—elevates the event to a Successful Exploit Confirmation.

Three Detection Categories

The initial rollout focuses on three areas, with plans to expand over time:

• Exploit attempts. Inspecting the full request-to-response cycle to identify input exploitation such as XSS and SQLi via malicious signatures, stop automated abuse like vulnerability probing, and confirm successful exploits by correlating suspicious requests with anomalous server responses.
• Data exposure and exfiltration signals. Catching data exfiltration that enters as legitimate-looking traffic. A request to /api/v1/export is a standard administrative action. If the response contains thousands of credit card numbers, flagged via Luhn algorithm signatures, the transaction is marked as Data Exposure.
• Misconfigurations. Exposed admin interfaces often evade traditional checks because the traffic is valid; the problem is public accessibility, not the request itself. Detection prioritizes common real-world misconfigurations seen in customer data, including public unauthenticated Elasticsearch clusters, internet-reachable admin panels, and exposed Apache sensitive endpoints.

Visibility First, Blocking Later

Detection results, like Attack Signatures, are stored in two dedicated fields accessible in the dashboard and logged within Security Analytics.

The initial focus is visibility: surfacing events on potential exploits so customers can drive incident response through targeted remediations across their infrastructure and stack. Future plans include extending Security Rules to the response phase, enabling policy creation to block responses based on these detections.

^{A diagram illustrating the execution locations and corresponding populated fields for both Attack Signature Detection and Full-Transaction Detection.}

Attack Signature detection is currently in Early Access, while Full-Transaction Detection is under development. To gain access to Attack Signature, sign up here. To express interest in Full-Transaction Detection, register here. Feedback gathered in the coming months will shape these features as they head toward General Availability.