Always‑On Attack Signature Detection: Eliminating the WAF Log vs Block Trade‑off
The new always‑on detection model separates identification of malicious payloads from enforcement, giving complete visibility while maintaining performance. By applying Attack Signature Detection to every request and optionally extending to Full‑Transaction Detection, security teams can eliminate the traditional log‑only versus block‑only dilemma and reduce false positives in real time for organizations.
Traditional Web Application Firewall Workflow
Classic Web Application Firewalls start in logging mode when a new site is added. Teams review alerts, adjust rule sets, and only later switch to blocking mode. This two‑step process slows deployment and creates a gap where attacks may pass unchecked while analysts confirm rule safety.
Attack Signature Detection Fundamentals
Attack Signature Detection runs a library of signatures against each incoming request. When a signature matches, metadata such as the signature ID, category and confidence level is attached to the request. The detection itself does not block traffic, allowing analysts to see every match in security dashboards.
Always‑On Framework Architecture
The always‑on framework decouples detection from mitigation. Detection runs continuously as traffic is proxied, and the resulting data is stored in fields like cf.waf.signature.request.confidence. Security policies can later reference these fields to decide whether to block, challenge, or log the request.
Full‑Transaction Detection Advantages
Full‑Transaction Detection expands analysis to include the server response. By correlating request and response data, the engine can spot threats such as reflective SQL injection or data exfiltration patterns that only appear after the origin server replies. This broader view sharply lowers false positive rates.
Understanding Confidence Levels and Categories
Each signature carries a confidence level indicating how likely it is to be a true positive. High confidence signatures target well‑known exploits with minimal risk of false alerts. Medium confidence signatures cover more ambiguous patterns and are disabled by default administrators should test them before enabling blocking actions. Signatures are also grouped by categories such as SQLi, XSS, RCE or specific CVE identifiers.
Leveraging Detection Data in Security Analytics
The metadata collected by the always‑on engine feeds directly into Security Analytics. Analysts can build queries on the confidence array, category list, or reference IDs to monitor attack trends, tune policies, and produce reports that illustrate how signatures interact with real traffic.
Performance and Deployment Considerations
When no blocking rule references a detection, the engine can run after the request reaches the origin, adding no measurable latency. If a rule uses detection data for inline blocking, the engine executes before the request is forwarded, introducing a small, traffic‑dependent delay. This design balances security with speed for production environments.