# WAF の検知失敗をルールで拾える！ failed_detections フィールドが登場

やっほー、しぃちゃんだよ！
今日は WAF のルールがちょっと賢くなるニュースを見つけたからみんなに紹介するね。セキュリティ検知が「失敗」したときの扱いを、ルール側で決められるようになったの！

## なにが発表されたの？

Cloudflare の Changelog で、Rules に新しいフィールド `cf.appsec.request.failed_detections` が追加されたと発表されたよ！

このフィールドは、セキュリティ検知が失敗を報告したときに、そのリクエストをルールでどう扱うかを選べるようにするものなの。中身は検知 ID の文字列の配列(Array of String)で、失敗が報告されなかったときは `[]` が返ってくるよ。

失敗を報告してくる検知は次のとおり！

- コンテンツスキャン
- WAF アタックスコア
- アタックシグネチャ検知
- 漏洩した認証情報の検知
- AI プロンプト検知(個人情報 PII・プロンプトインジェクション・カスタムトピック・unsafe トピック)

## なぜ重要なの？

セキュリティ検知は、いつでも必ず判定を出せるとは限らないよね。検知が失敗したリクエストを、ルールの側で「通す」のか「止める」のか「ログを残す」のかを選べないと、運用の方針に合わせた守り方がしづらいの。

このフィールドがあれば、その失敗をルールの条件として明示的に扱えるんだよ。

## これで何が変わるの？

大事なのは、**既存の検知の動作は変わらない**こと。新しいフィールドは、報告された失敗に対してルールでどう反応するかを決めるための材料なの。

だから、たとえばこんな使い方ができるよ。

- 検知が失敗したリクエストだけを狙って、チャレンジやブロックなどのアクションを当てる
- 失敗が起きたリクエストにだけ、レート制限をかける
- 失敗が起きたことを、リクエストヘッダーに付けてオリジン側へ伝える(Request Header Transform Rules)

セキュリティ担当の人は、検知の抜け穴を自分たちのポリシーで塞げるようになるね。

## 深く潜ってみよう

使えるルールの種類は次のとおり！

- ゾーンレベルとアカウントレベルのカスタムルール
- ゾーンレベルとアカウントレベルのレート制限ルール
- ゾーンレベルの Request Header Transform Rules

プランは全プランで使えるよ。ただし、使いたい検知やルール機能そのものは、契約しているプランに含まれている必要があるの。

式の例も載っていたよ。失敗がひとつでも報告されたらマッチさせるときはこう書くの。

```
len(cf.appsec.request.failed_detections) gt 0
```

漏洩した認証情報の検知の失敗だけにマッチさせるときは、検知 ID を指定するよ。

```
any(cf.appsec.request.failed_detections[*] eq "waf_credential_check")
```

発表の中で検知 ID として例に出ていたのは `waf_credential_check` だけだったよ。ほかの ID は、Cloudflare のドキュメントにある Failed detections フィールドのリファレンスで確認してね。

## まとめ

- 新フィールド `cf.appsec.request.failed_detections` で、検知の失敗をルールの条件に使える
- 値は検知 ID の配列で、失敗がなければ `[]`
- 既存の検知の動作は変わらない
- カスタムルール・レート制限ルール(ゾーン/アカウント)と、ゾーンの Request Header Transform Rules で使える
- 全プランで使えるけど、検知とルール機能が自分のプランに含まれている必要がある

WAF や Bot 対策の運用で「検知が失敗したときの挙動」まで自分で握りたい人に刺さる更新だよ！