Cloudflare now surfaces cf.appsec.request.failed_detections, an array that lists the IDs of any security detections that reported a failure for a given request. The addition does not change how detections work; it simply provides a hook for rule authors to react to those failures. Engineers responsible for WAF, rate limiting, or request‑header transformations can now branch logic on the presence or type of detection, enabling more precise handling of risky traffic.
How the field can be used in rule expressions
The array is empty ([]) when no detection fails. A simple truth test confirms any failure exists:
len(cf.appsec.request.failed_detections) gt 0Targeting a specific detection, such as a leaked‑credential check, uses the any operator:
any(cf.appsec.request.failed_detections[*] eq "waf_credential_check")These snippets can be placed in any of the supported rule types: custom rules at zone or account scope, rate‑limiting rules at zone or account scope, and request‑header transform rules at the zone level.
Operational considerations
- Plan requirements: The field is available on all Cloudflare plans, but the underlying detections (content scanning, attack score, AI prompt checks, etc.) must be part of the subscribed feature set.
- Rule complexity: Adding array checks introduces minimal latency, but operators should monitor rule evaluation time if many detections are listed.
- Observability: Because the field returns explicit detection IDs, logs can be enriched with the same IDs, simplifying correlation between rule actions and detection sources.
Security implications
Having visibility into which detection triggered a failure allows security teams to prioritize response. For example, a rule could block requests that include a "waf_credential_check" failure while merely logging others, reducing false‑positive impact on legitimate traffic. The field does not replace existing detection enforcement; it merely offers a decision point for downstream actions.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Review existing custom, rate‑limiting, and header‑transform rules and identify where a detection‑aware branch could improve outcomes. Add the len(... ) gt 0 guard to catch any failure, or use any(... eq " for targeted handling. Monitor rule evaluation latency and log the detection IDs to verify that the new logic behaves as intended. Finally, confirm that your plan includes the specific detections you intend to act upon, otherwise the field will remain empty and the rule will never match.