WEBサイトCloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）
CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）
目次
01 何が書いてあるか — CloudflareのWAFが「応答」も見る検知を、Freeを含む全プランに入れた
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflareのブログからの引用で、日本語訳は記事の筆者が付けたものである。原文は出典のページで確かめられる。ページは2026年10月23日に開いて、本文を取り直して確かめた。
2026年10月21日に公開された記事
Cloudflareのブログ「Introducing full transaction detection for Cloudflare WAF」（訳: CloudflareのWAFのfull transaction detectionの紹介）は、2026年10月21日付である。書き手は、Daniele Molteni、Elie Roudninski、Nick Downieの3人と表示されている。記事は、WAF（Webアプリケーションファイアウォール）に、2つの新しい機能を足したと書く。
1つ目は「full transaction detections」で、記事は次のように説明する。
"Full transaction detections evaluate each HTTP request alongside its response to identify evidence of exploitation."
（訳: full transaction detectionsは、それぞれのHTTPリクエストを、その応答とあわせて評価し、攻撃が成功した証拠を見つける。）
2つ目は「response rules」（応答に対するルール）で、一致した応答を、リクエストした側に届く前に止められる、と書かれている。この記事では、1つ目を「リクエストと応答を合わせて見る検知」、2つ目を「応答のルール」と呼ぶ。
使える範囲は、原文の書き方のまま
使える範囲は、プランによって書き方が分かれている。思い込みで広げないように、原文の言い方を、そのまま整理する。
- 全プランで一般提供 — 記事は、これらの機能を「Freeプランを含む、すべてのCloudflareの顧客」に一般提供すると書く。対象は、Cloudflareを通して通信を中継しているゾーンである。
- 管理された検知（Managed Response Firewall Default） — すべての顧客に配備される。止めるときは、標準のWAFのブロック画面を返す。
- 応答のカスタムルール — すべての顧客が、3本まで作れる。動作は、記録（Log）とブロック（Block）の2つである。
- 検知の結果を使うフィールド — 有料プランの顧客向けで、現在、全アカウントへ展開している最中と書かれている。
- 応答の本文を条件にしたルール — 記事は「まだできない」と書く。
最後の2つは、書かれた時点の状態である。画面に出ているかは、アカウントごとに違うかもしれない。これは、04章の🅰で、もう一度扱う。
02 なぜ起きたか — リクエストだけでは、攻撃かどうかを決めきれない場面がある
広く止めると誤検知、狭く止めると見逃し
記事は、CloudflareのWAFのこれまでのルールが、リクエストの段階で動くと書く。IPアドレス、URLのパス、ヘッダー、リクエストの本文などの条件で、通すか止めるかを決める仕組みである。多くの攻撃には、それが正しい置き場所だと、記事も認める。
ただし、疑わしいリクエストを、すべて「攻撃が成功した」と扱うと、難しい選択が生まれる、と記事は続ける。広い条件のルールは、攻撃をよく捕まえるが、正当な通信まで止める（誤検知）ことがある。誤検知を避けて、確実なルールだけを入れると、あいまいな通信がサーバーまで届く余地が増える。
応答は「実際に何が起きたか」の証拠になる
記事は、この問題に、応答という証拠を足す。
"The response provides the missing evidence."
（訳: 応答が、欠けていた証拠を与える。）
記事の例は、ファイルをダウンロードさせる画面である。攻撃者が、パスの指定を書き換えて、許可された場所の外にある設定ファイルを取ろうとする。リクエストの形だけでは、そのファイルが実際に返されたかは分からない。拒否されたか、無視されたか、エラーになったかもしれない。サーバーが「200 OK」で設定ファイルのような中身を返したときに、初めて「流出した」と言える。同じ入力でも、拒否された場合と、中身が返った場合では、意味が違う、というのが記事の考え方である。
php2shellの保護が、最初の使い道だった
記事は、AIを使った脆弱性の探索が、応答の反応を見ながら攻撃の形を変えていくことを、背景に書く。応答が「うまくいった」ことを教えてしまうと、攻撃者は次の手を打ちやすい。そのため、応答の側にも目を置く、という理屈である。最初の管理された検知は、直前に公表されたPHPの脆弱性（php2shell）に向けたもの、と記事は書く。同じ日のCloudflareの別のブログも、この検知を最初に使ったのはphp2shellの保護だったと書く。
php2shellそのものの説明、WAFがあってもPHPの更新が要る理由、CDNを通らない経路の確かめ方は、当サイトのPHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）に書いた。この記事は、それを繰り返さない。新しく入った検知の、確かめ方の手順に絞る。
検知と対処を、別々の仕事にしている
記事は、設計の方針も書く。
"Detections analyze traffic and attach metadata to the request and response, rules then decide what to do with those results."
（訳: 検知は通信を分析して、リクエストと応答に付随情報を付ける。そのあと、ルールが、その結果をどうするかを決める。）
この分け方には、利点がある。止める前に、自社の通信で、どのエンドポイントがどの検知に当たるかを見られる。見てから、止めるルールを作れる。次の図は、通信の流れと、応答を見る場所を描いている。
03 この記事に出てくる用語
WAF（Webアプリケーションファイアウォール）
Webサイトへの通信を、規則に照らして検査し、通すか止めるかを決める仕組みをいう。Cloudflareのような中継の事業者が提供するものがある。
オリジン
中継の後ろにある、本来のサーバーをいう。アプリケーションやPHPが動いているのは、このオリジンである。応答を作るのも、オリジンである。
リクエストと応答
リクエストは、ブラウザや攻撃者のプログラムが、サイトに送る問い合わせをいう。応答は、サイトがそれに返す答えをいう。応答には、HTTPのステータス（200・403など）、ヘッダー、本文が入る。
full transaction detection
同じ通信（トランザクション）の中のリクエストと応答を、対にして見る検知をいう。記事は、最初の検知が「高く注目されている脆弱性」の、攻撃が成功した証拠を見つけることに絞られている、と書く。
応答のルール（response rules）
オリジンが返した応答を条件にして、止めるか記録するかを決めるルールをいう。一致して止めるときは、Cloudflareが応答を、WAFのブロック画面か、用意した応答に差し替える。
Managed Response Firewall Default
Cloudflareが作って更新を続ける、応答用の既定のルールのまとまりをいう。記事は、1回の操作で配備できる設計で、設定を簡単にしたものと書く。標準では、すべてのリクエストに対して動く。
Security AnalyticsとSecurity Events
CloudflareのWAFの記録を見る画面である。記事は、検知の結果をSecurity Analyticsで見て、止めたり記録したりした出来事をSecurity Eventsで追える、と書く。
誤検知
正当な通信を、攻撃と取り違えて止めることをいう。誤検知が多いと、利用者が使えなくなる。記事が「応答を見る」理由の1つは、この誤検知を減らすことである。
用語
パストラバーサルとは、「../」のような指定で、許可された場所の外にあるファイルを取りに行く攻撃をいう。記事の例では、ダウンロードの画面で、設定ファイルを取ろうとする形として出てくる。
04 型別 — 新しい検知を、3つの観点で読む
🅰 適用範囲 — 誰が、何を使えるか
使える範囲は、次の図と表のとおりである。プランの名前や数字は、すべて、記事の書き方のままにした。
全プランで使えるもの
管理された検知は、1回の操作で配備できる形で、標準ではすべてのリクエストに対して動く。配備されているかは、管理画面の「Security > Security Rules」で確かめられる、と記事は書く。応答のカスタムルールは、すべての顧客が3本まで作れる。使える動作は、記録とブロックである。条件に使える項目は、リクエストのカスタムルールで、そのプランが使える項目と同じ、と記事は書く。
有料プランで拡がるもの
有料プランの顧客は、検知の結果を表す3つのフィールドを、ルールの条件に使える。フィールドは、一致した署名の確信度（confidence）、分類（categories）、署名の参照番号（ref・最大10個）である。名前は、cf.waf.signature.response.で始まる。これらは、ホスト名・URLのパス・接続元のIP・ヘッダーなどと組み合わせて、1つのパスだけを守る、といった使い方ができると書かれる。
記事はここで、「現在、全アカウントに展開している」と書く。まだ画面にない人は、アカウントの担当者に連絡するように、との案内である。
"We are currently rolling out the response fields to all our accounts."
（訳: 私たちは現在、応答のフィールドを、すべてのアカウントに展開している。）
まだできないこと
"Creating rules on the response body is not yet available."
（訳: 応答の本文を条件にしたルールの作成は、まだ使えない。）
したがって、応答の本文の中の語を条件にした、自作のルールは、今は作れない。作れるのは、リクエストと、応答のステータスやヘッダーなどを組み合わせたルールである。
🅱 この記事が測っていないこと
この記事は、Cloudflareのブログを読んで書いた。自社のCloudflareの画面は開いていない（当サイトはCloudflareを使っていない）。次のことは、記事から分からない。
- 検知が実際にどれだけ当たるか — 件数・誤検知の割合は、記事に書かれていない。
- 応答を見ることで、通信が遅くなるか — 記事の本文に、遅延や負荷の話は書かれていない。
- 開発者向けの手順書の中身 — Cloudflareの開発者向け文書（2026年10月23日に確かめた範囲）では、応答のルールの専用ページを見つけられなかった。ルールの言語の「フェーズ」の一般的な説明（2026年4月16日更新）は、あった。
止めても、オリジンの中で済んだことは取り消せない
記事は、応答のルールの限界を、はっきり書いている。
"Response custom rules turn full transaction detections into inline protection by blocking a matching origin response before it reaches the requester, although it cannot undo actions already performed at the origin."
（訳: 応答のカスタムルールは、full transaction detectionの結果を、通信の途中に入る保護にする。一致したオリジンの応答を、リクエストした側に届く前に止める。ただし、オリジンがすでに行った処理は、取り消せない。）
つまり、サーバーの中でコードが動いてしまった場合は、応答を止めても、それは終わらない。応答のルールは、情報が外に出るのを防ぐ層であって、サーバーの中の欠陥を直す層ではない。この点は、同じ日のCloudflareのphp2shellの記事が、次のように書く、PHPの更新の話とつながる。
"Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation."
（訳: 顧客は、WAFの保護が追加の多層防御の層になっていても、PHPの環境を更新するべきである。）
🅲 手順 — 画面で状態を見る
記事が「保護されているかを確かめるには」と書く手順は、1つである。Cloudflareの管理画面で、Security > Security Rulesを開く。そこに、応答の段階の設定が、ページの一番下に出ている、と記事は書く。管理された保護も、自作のルールも、同じ場所にある。
手順 — 検知の結果を、先に見る
止めるルールを作る前に、Security Analyticsで、full transaction detectionの結果を見る。記事は、これを勧める。見る点は、どのエンドポイントが当たっているか、どの署名が関わっているかである。見たあとで、自社のアプリケーションに合った、応答の段階の方針を決める。
手順 — 管理された保護の範囲を絞る
Managed Response Firewall Defaultは、標準では、すべてのリクエストに動く。記事は、次のように書く。
"To reduce the risk of false positives, customers can restrict the scope of the mitigation to a portion of their application."
（訳: 誤検知の危険を減らすために、顧客は、この緩和策の範囲を、自分のアプリケーションの一部に絞れる。）
範囲の絞り方は、原文では、特定のパスを除く、特定のパスだけに限る、という例が挙がっている。絞ると、誤検知は減るが、絞った外側は守られない。絞ったときは、外れたパスを、一覧に書いておく。
手順 — 自作の応答ルールは、記録から始める
自作のルールの動作には、記録とブロックがある。記事の例は、管理画面（/admin）が、認証されていない通信に対して、成功の応答（200）でHTMLの管理画面を返してしまうことを止めるルールである。
| 条件 | 記事の例の書き方 | 読み方 |
|---|---|---|
| 対象のパス | /admin で始まる | 管理画面のパスだけを見る |
| 認証の印 | x-internal-user が true でない | 認証の入口が「社内の利用者」と印を付けていない通信 |
| 応答のステータス | 200 | オリジンが成功の応答を返した |
| 応答の種類 | content-type が text/html を含む | HTMLの画面が返った |
記事は、このルールが、通常の認証の失敗、転送、管理画面以外の通信を止めない、と書く。つまり、4つの条件がすべて当てはまったときだけ動く。自分のサイトに合わせるときは、印のヘッダーの名前や、パスが違う。条件を変えたあとは、最初は記録だけで動かして、本当に当たるものを見てから、ブロックに変える。ここは、記事に書かれた手順ではなく、誤検知を避けるための筆者の勧めである。
参考になる書き方が、Cloudflareの開発者向け文書にある。管理されたルールの更新では、新しいルールを最初の1週間は「Log」の動作で入れ、その間に、予期しない一致がないかを見てほしい、と書かれている（WAFの変更履歴の概要・最終更新2026年8月26日）。この文書が書くのは、リクエストを見る管理ルールの更新の周期で、応答のルールの運用ではない。考え方として借りるだけである。
画面の順に書いた手順（Logから始めてBlockへ）
管理画面の順に並べると、次のようになる。1〜3と5は記事に書かれた画面と項目で、4と6は筆者の勧めである。
- Security > Security Rulesを開き、ページの一番下の応答の段階で、管理された保護が配備されているかを見る。
- Security Analyticsで、full transaction detectionの検知を見て、当たったエンドポイントを控える。
- 応答のカスタムルールを作る。条件は、リクエストの項目と応答の項目を組み合わせる。
- 動作は、まずLog（記録）にする（筆者の勧め）。
- Security Eventsで、そのルールのIDで絞り込み、当たった通信を読む。
- 正当な通信が混ざっていないと分かってから、動作をBlockに変える（筆者の勧め）。
05 明日、自社のサイトで確認できることチェックリスト
以下は、新しい検知と応答のルールについて、自社の状況を書き出す13項目である。1〜9番目はCloudflareを使っているサイト向け、10〜13番目はCloudflareを使っていないサイトも含めて、サーバーの側で確認する項目である（1番目は、どちらにも使える）。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 自社が使っている中継（CDN）とWAFの事業者名を、担当サイトの一覧に1行ずつ書き出す
- Cloudflareを使うサイトの管理画面で、Security > Security Rulesを開き、ページの一番下の応答の段階にManaged Response Firewall Defaultが出ているかを確認する
- Managed Response Firewall Defaultの適用範囲に、除外のパスや限定のパスが付いていないかを読み、付いているパスの数を書き出す
- Security Analyticsを開き、直近7日間で、full transaction detectionの検知が出ているかを確認し、件数を控える
- 検知が出ているときは、当たったエンドポイントを上位5つ書き出す
- 応答のカスタムルールが何本あるかを数え、動作が記録かブロックかを、1本ずつ書き写す（上限は3本）
- ブロックにしている応答のルールが1本もないかを確認し、あれば、直近30日の件数をSecurity Eventsで数える
- Security Eventsで、応答のルールのIDを指定して絞り込めるかを、1回試す
- 有料プランのサイトで、
cf.waf.signature.response.で始まるフィールドが、ルールの編集画面に出るかを確認し、出ないときは「展開待ち」と記録する - 管理画面のパスを3つ書き出し、認証していない状態のブラウザで開いて、ログインの画面や拒否の応答になることを確認する
- アプリケーションが「成功の応答（200）」のまま、エラーの文面や設定の中身を返す場所がないかを、担当者に聞いて、あれば一覧に書く
- PHPなどサーバーの中のソフトの更新担当者に、「応答のルールは、更新の代わりにならない」と1行で伝え、更新の予定日を聞く
- 確認した日、数えた数字（本数・件数・除外のパス）、次に見直す日を、記録に書く
1番目の確認の前に、サイトの外から、使っているCDNやWAFがどう見えるかを知りたいときは、当サイトの無料ツールの1つ、🔧 外からできるセキュリティ対策監査ツールが使える。ツールのページによれば、外からの調査として、WebテクノロジーのうちCDNやWAFの検出、ディレクトリ・ファイルの探索、APIの入口の検出を含む。会員限定のツールで、自分が管理するサイトにだけ使う。Cloudflareの応答のルールの設定が有効かを判定する、とはページに書かれていない。
各ページの基本の設定（タイトル・meta description・canonical・見出し・セキュリティヘッダー）を、まとめて見たいときは、🔧 WEBサイト総合分析・レポートツールが使える。ページによれば、HTTPS対応とセキュリティヘッダー（HSTS・CSP・X-Frame-Options）の点検を含む。応答の検知の判定は、含まれない。
06 代替・他の選択肢 — 応答を見る検知と、他の層の分担
次の表は、記事に書かれた範囲で、層ごとの役割を並べたものである。表の「できないこと」の列は、記事の書き方と、記事に書かれていないことの区別を、列の見出しで分けてある。
| 層 | 見るもの | 記事が書くこと | 記事が書かないこと |
|---|---|---|---|
| リクエストのルール | IP・パス・ヘッダー・本文 | 既知の攻撃の形を、オリジンに届く前に止める。誤検知の危険がある | どの形をどれだけ見逃すか |
| 応答のルール | 応答のステータス・ヘッダー（本文はまだ） | 成功の証拠が見えた応答を、届く前に止める。オリジンの処理は取り消せない | 誤検知の件数、遅延への影響 |
| 認証の入口 | 利用者の確認 | 記事の例は、認証の入口が付ける印を条件に使う | 認証の作り方そのもの |
| サーバーの更新 | PHPなどの実行環境 | 同日の別の記事が「更新するべき」と書く | 更新の手順（別の公式の文書に書かれる） |
従来の検知と、リクエストと応答を対にした検知の比較
次の表は、記事に書かれた範囲の比較である。記事が書かないことは、「書かれていない」と書いた。
| 比べる点 | リクエストだけを見る検知 | リクエストと応答を対にして見る検知 |
|---|---|---|
| 見るもの | IP・パス・ヘッダー・本文 | リクエストと、その応答 |
| 得意なこと | 既知の攻撃の形を、サーバーに届く前に止める | 攻撃が成功した証拠を見つけ、応答を届く前に止める |
| 弱いところ | 広く止めると誤検知、狭く止めると見逃しが増える | オリジンの中で済んだ処理は取り消せない。応答の本文はまだ条件にできない |
| 件数・精度 | 書かれていない | 書かれていない |
場面ごとの使い道
- PHPなどの重大な脆弱性が出た直後 — 管理された保護が、更新までの間の追加の層になる。同日の別の記事によれば、Cloudflareは公表の約9時間前に保護を展開し、PHPは約70%のサイトで使われている。
- 管理画面を守りたいとき — 記事の例のように、認証されていない通信に、成功の応答が返らないようにする。
- 誤検知が心配なとき — 管理された保護の範囲を、パスで絞る。
Cloudflareを使わないサイトの選択肢
この記事は、他社のWAFの機能を確かめていない。応答も見る検知が自社のWAFにあるかは、事業者の最新の文書で確かめてほしい。ない場合に取れる選択肢を、言い切らずに並べる。
- オリジン側の更新 — 同日の別の記事は、WAFがあってもPHPを更新するべきだと書く。更新が先の選択肢である。
- ログの見張り — 応答のステータスや、管理画面への未認証のアクセスを、サーバーのログで数える方法がある。当サイトの記事「PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）」の考え方が使える。
- ほかのWAFの検討 — 応答を見る機能があるかは製品ごとに違うので、事業者に聞いて確かめる。
応答のルールを使わない、という選択
管理された保護は、標準で動いている。自作のルールを書かない、という選択もある。その場合は、管理された保護の範囲と、除外したパスの一覧だけを、記録しておく。自作のルールを書くのは、管理画面のような、守る対象がはっきりしている場所に限るほうが、運用が続きやすい。これは筆者の考えで、記事の内容ではない。
実務のヒント
応答のルールの画面を初めて開く担当者は、最初の15分で、管理された保護の範囲と、応答のカスタムルールの本数の2つだけを書き写す。設定を直す前の状態を残しておくと、あとで「何を変えたか」が分かる。
注意
管理画面を守るルールを試すときは、自社が管理するサイトでだけ確認する。他人のサイトに、パスを書き換えたリクエストを送らない。また、ブロックにしたルールが誤って正当な通信を止めると、利用者や担当者が管理画面に入れなくなる。まず記録で動かし、止める前に、入れなくなったときの戻し方を決めておく。
07 当サイトで確かめたこと — 確かめていないことの範囲
当サイトは、Cloudflareを使っていない。したがって、この記事のCloudflareの画面の操作は、当サイトでは試していない。Cloudflareのブログと、開発者向けの文書を読んだ範囲で書いた。
この記事は、サーバーの設定の中身や、防御の設定の値を書かない。書くのは、公式の文書が公開している範囲と、自分のサイトで同じ考え方を試すための確認項目である。
当サイトのPHPの更新と、更新の後の確認は、AI RonのブログのPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いた。WAFの記事を書いたあとで、当サイトで実施していなかったことが分かり、訂正した経緯は、Verified AI Agent 37体を個別allowする WAF ルールの書き方 ── 当サイトでは実施していなかった（2026年10月4日 訂正）に残してある。WAFの記事を読んで「自分のサイトにもある」と思い込む前に、自分の画面で確かめる。この教訓は、今回も同じである。
2026年10月23日 追記 — 一覧に出ていることと、応答に効いていることは別だった
公開した日の午後、同じチームが運営するAlbum Sweet（Cloudflareを使っている）で、運営の担当が管理用のAPIを使って確かめた。APIで取ったルールセットの一覧には、Managed Response Firewall Defaultが出ていた。一方で、応答の段階でルールを置く場所を読むと、管理された検知の側も、カスタムルールの側も、まだ何も展開されていない状態だった。
01章で整理したとおり、Cloudflareのブログは、管理された検知がすべての顧客に配備されると書いている。今回の結果は、1つのサイトで1回確かめただけで、展開が途中なのか、利用者の側で別の操作が要るのかは、まだ分からない。一覧に名前が出ていることを、応答に効いていることの証拠にしない。05章の2番目の項目で名前が出ていたら、4番目の項目（Security Analyticsで応答の段階の検知が記録されているか）まで合わせて見る。
08 このテーマは、ここまで
2026年10月20日 — PHPの事前告知
PHPの開発元が、重大なセキュリティリリースの予定を、事前に告知した。この日の内容は、当サイトの記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」に書いてある。
2026年10月21日 — 2つのCloudflareの記事
Cloudflareは、同じ日に、2本のブログを公開した。1本は、php2shellに対する保護の配備（午前3時2分UTCから、無料または有料のWAFを使う顧客が、既定で保護された、と書く）である。もう1本が、この記事で扱った、full transaction detectionと応答のルールの紹介である。php2shellの記事は、新しい検知を、この保護のために作ったと書く。
2026年10月23日 — この記事の確認日
この記事は、2026年10月23日に、Cloudflareのブログ2本と、開発者向け文書のページを開いて確かめた時点の内容である。展開中と書かれたフィールドや、まだ使えないと書かれた本文の条件は、今後変わりうる。出典のページが更新されたときは、この記事に日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
