Always-on detections: eliminating the WAF “log versus block” trade-off (opens in new tab)
Traditional WAFs force teams to choose between broad visibility in logging mode and active protection in blocking mode. Cloudflare’s new always-on detection model separates attack detection from mitigation, allowing every signature to inspect traffic and provide metadata without immediately blocking requests. Attack Signature Detection is available in Early Access, while Full-Transaction Detection is planned to improve accuracy by analyzing both requests and responses. ## The Always-On Framework - Detection signatures run on every proxied request for opted-in customers. - Results appear in Security Analytics and are added to request metadata usable by custom security rules. - Detection is separated from mitigation: - Signatures identify suspicious traffic. - Security rules decide whether to block, challenge, or otherwise handle it. - This preserves visibility into all matching signatures, even when one detection leads to a mitigation action. - Initially, detections can run after the request is sent to the origin, avoiding added latency. - Once a blocking rule depends on a detection, that detection runs inline and may add latency based on the application’s traffic profile. - Bot Score and Attack Score already use this detection model. ## Attack Signature Detection - The system uses the same analytical heuristics as Cloudflare Managed Rules but does not directly apply traffic actions. - It covers attack types such as: - SQL injection - Cross-site scripting - Remote code execution - Specific CVEs - Cloudflare’s Managed Ruleset contains more than 700 active rules, with new rules generally released weekly and emergency rules released for major vulnerabilities. - Each signature has: - A unique Ref ID - One confidence level - One or more attack categories - Confidence levels indicate expected false-positive risk: - **High:** Designed for high true-positive rates and low false positives; comparable to default Managed Rules behavior. - **Medium:** More likely to cause application-specific false positives and should be assessed before blocking. ## Detection Metadata Attack Signature Detection exposes three fields in Security Analytics and the Edge Rules Engine: - `cf.waf.signature.request.confidence` - An array of confidence values for matching signatures. - `cf.waf.signature.request.categories` - An array of matched attack categories, such as SQLi or XSS. - `cf.waf.signature.request.ref` - An array of up to 10 matching signature Ref IDs. These fields let teams create precise policies based on observed traffic rather than relying on broad, manually tuned rules. ## Using Security Analytics for Onboarding - Detection begins collecting data as soon as an application is proxied through Cloudflare. - Teams can review aggregate matches by signature and attack category. - Analysts can compare matches against request outcomes, including: - Blocked requests - Cached responses - Requests delivered to the origin - If malicious traffic reaches the origin, teams can quickly create appropriate security rules. - Analytics also helps identify false positives and determine where exceptions are needed. ## Full-Transaction Detection - The planned system will analyze the complete HTTP transaction, including both request and response. - Correlating both sides should reduce false positives compared with request-only engines. - It may detect threats that request analysis misses, including: - Reflective SQL injection - Subtle data-exfiltration behavior - Dangerous misconfigurations visible only in responses The practical recommendation is to enable Attack Signature Detection during application onboarding, use its metadata and analytics to understand real traffic, and then create targeted mitigation rules. This preserves continuous visibility while allowing teams to deploy blocking protections with greater confidence.