Cloudflare 05：WAF ― リクエストの中身を読んで止める

WAF は、リクエストの「中身」を見る門番

そこで登場するのが WAF（Web Application Firewall）です。

ふつうのファイアウォールは、「どこから来たか（送り元の IP）」「どこへ行くか（宛先のポート番号）」しか見ません。443番ポートへの通信を許可したら、その中身が何であっても通します。

WAF は、そこから一歩踏み込んで、HTTP のリクエストの中身を読みます。URL のパスやクエリ、ヘッダー、Cookie、フォームで送られた本文などを見て、「攻撃の型」に当てはまるものを止めます。

Cloudflare の WAF はエッジで動くので、悪いリクエストはオリジンに届く前に止まります。アプリにまだ直していない穴があっても、その穴を突くリクエストがそもそも届かなければ、時間を稼げます。新しい脆弱性が公表されたとき、アプリの修正が間に合うまでのつなぎになるのが、WAF の大きな役割です。

Cloudflare の WAF は、大きく2種類のルールでできています。

図のエッジの中にある3つの段が、それぞれの置き場所です。真ん中のレート制限は06号で扱います。

マネージドルール：Cloudflare が書き、更新し続ける

マネージドルールは、Cloudflare のセキュリティチームが書き、更新し続けているルールの束（ルールセット）です。利用者は、オンにするだけで使えます。

Cloudflare は非常に多くのサイトの通信を見ているので、新しい攻撃の流行や、新しく公表された脆弱性にすばやく反応できます。大きな脆弱性が公表されたとき、その日のうちにルールが追加されることもあります。自分で攻撃の研究をしなくても、その成果を借りられるのが、マネージドルールの価値です。

主なルールセットは次のとおりです。

ルールセットの中の1本1本は、管理画面から個別にオフにしたり、動作を変えたりできます。自分のサイトで使っていない技術（たとえば PHP を使っていないのに PHP 向けのルール）は、オフにしても構いません。

OWASP ルール：怪しさを点数で足していく

OWASP Core Ruleset は、ほかのルールと少し違う考え方で動きます。1つの特徴が当たっただけでは止めず、怪しさを点数で足していくのです。

図のように、「SQL で使う記号の並びがある」「UNION SELECT という語がある」「コメント記号がある」といった特徴が見つかるたびに、そのリクエストに点数が足されます。合計点が閾値（しきいち）を超えたときに、はじめて止めます。図の点数は説明のための例です。

こうする理由は、誤検知を減らすためです。たとえば「-- が含まれる」だけで止めると、文章中のダッシュまで止めてしまいます。いくつもの怪しい特徴が重なったときだけ止めれば、正しいリクエストを巻き込みにくくなります。

調整できる主なつまみは2つです。

どの特徴で何点ついたかは、Security Events（セキュリティのイベント一覧）で確かめられます。最初は厳しすぎない設定から始め、ログを見ながら締めていくのが定石です。

カスタムルール：自分のサイトの事情を書く

マネージドルールは「世の中によくある攻撃」を止めます。でも、あなたのサイトだけの事情は、Cloudflare には分かりません。

これらを書くのがカスタムルールです。図の下にあるのは、「パスが /admin で始まり、かつ送り元の国が日本（JP）ではない」ときに止めるルールです。

カスタムルールは、エッジの中でいちばん先に評価されます。自分のサイトについてはっきり分かっている規則を先に当て、その後ろで、マネージドルールが一般的な攻撃を見る、という役割分担です。

管理画面では、項目と比べ方をプルダウンから選んでルールを組み立てられます。慣れてきたら、次のページで見る「式」を直接書くこともできます。

式の言葉：「項目・比べ方・値」をつなぐ

カスタムルールの条件は、Cloudflare のルールの言葉（Rules language）で書きます。形は「項目 比べ方 値」で、それを and や or でつなぎます。通信の中身を調べる道具 Wireshark の表示フィルターを元にした書き方なので、見たことがある人もいるかもしれません。

比べ方には、eq（等しい）、ne（等しくない）、in {…}（どれか）、contains（含む）、starts_with()（で始まる）などがあります。上位のプランでは、正規表現で比べる matches も使えます。

たとえば「/api/ の下への、POST でも GET でもないリクエスト」は次のように書けます。

starts_with(http.request.uri.path, "/api/")
and not http.request.method in {"GET" "POST"}

この言葉は WAF だけのものではありません。レート制限（06号）、ボットのルール（07号）、リダイレクトや書き換えのルール（09号）でも同じ書き方を使うので、一度覚えると Cloudflare 全体で役に立ちます。

当たったら何をするか：動作（アクション）

条件に当たったリクエストをどうするかを、動作（アクション）で決めます。主なものは次の4つです。

ほかに、必ず JavaScript の確認を挟む JS Challenge と、必ず操作を求める Interactive Challenge もあります。ただ、Cloudflare は多くの場面で Managed Challenge を勧めています。訪問者の様子を見て、必要なときだけ確認を出すので、人間の利用者への負担が小さいからです。Managed Challenge の裏で動いている仕組みは、08号の Turnstile とも共通しています。

注意したいのは、Challenge はブラウザ向けだということです。スマホアプリや、サーバー同士の API 通信は、確認の画面を表示できません。API のパスに Challenge を掛けると、正しいアプリの通信まで止まってしまいます。API には Block か、レート制限（06号）を使います。

順番が大事：カスタム → レート制限 → マネージド

エッジの中では、ルールが決まった順番で評価されます。

この順番がいちばん効いてくるのが、Skip を使うときです。Skip は「この後ろの段を飛ばす」動作なので、前の段には効きません。

よくある例で考えます。決済サービスから、あなたのサーバーの /webhook/pay に、支払いの通知（Webhook）が届きます。ところが、この通知の本文の形が、マネージドルールには怪しく見えて、止められてしまいました。

このとき、①のカスタムルールで「パスが /webhook/pay で、送り元が決済サービスの IP の範囲なら、③のマネージドルールを Skip する」と書けば、通知は③を通らずにオリジンまで届きます。図の小包がオリジンまで進んでいるのは、その様子です。

大事なのは、Skip の範囲をできるだけ狭くすることです。パスだけで Skip すると、攻撃者がそのパスを狙えば WAF を素通りできてしまいます。パスと送り元の IP、できればメソッドまで絞りましょう。

誤検知：正しいリクエストが止められる

WAF を入れたときに、いちばん悩まされるのが誤検知（false positive）です。攻撃ではない、正しいリクエストが止められてしまうことです。

誤検知が起きやすいのは、たとえば次のような場面です。

誤検知を放っておくと、「保存できない」「決済が反映されない」といった、原因の分かりにくい障害になります。

進め方は次のとおりです。まず Security Events を開き、止められたリクエストを探します。そこには、どのルールが、リクエストのどこを見て止めたのかが出ています。次に、そのルールだけ、そのパスだけを例外にします。ルールセット全体をオフにしたり、サイト全体で Skip したりするのは最後の手段です。

新しいルールを入れるときは、いきなり Block にせず、まず Log（使えるプランなら）や Managed Challenge で数日様子を見るのが安全です。

導入：管理画面でオンにし、ログを見ながら育てる

WAF の導入は、次の順で進めます。

場所は、管理画面のドメインの セキュリティ > WAF です。2025年からの新しいセキュリティの管理画面では、カスタムルール・レート制限・マネージドルールが「セキュリティルール」としてまとめて並んでいます。表示は変わることがあるので、見つからないときは公式のドキュメントで場所を確かめてください。

WAF は、オリジンの IP が漏れていると素通りされます。04号で見た「Cloudflare からしか受けない」設定は、WAF にとっても前提です。

使い方：よくあるカスタムルール

実際によく書かれるカスタムルールを3つ紹介します。

1. 管理画面は日本からだけ（動作：Block）

starts_with(http.request.uri.path, "/wp-admin")
and ip.src.country ne "JP"

2. ログイン画面への送信には確認を挟む（動作：Managed Challenge）

http.request.uri.path eq "/login"
and http.request.method eq "POST"

3. 決済の Webhook だけ、マネージドルールを Skip（動作：Skip）

http.request.uri.path eq "/webhook/pay"
and ip.src in {192.0.2.0/24}

192.0.2.0/24 は説明用の番号です。実際には、決済サービスが公開している送り元の IP の範囲を入れます。

書くときのコツは、1本のルールに1つの目的です。いろいろな条件を1本に詰め込むと、どれが効いて止まったのかが分からなくなります。ルールには、あとで読んで分かる名前を付けましょう。

ルールは管理画面のほか、API や Terraform（34号）でも管理できます。複数のドメインで同じルールを使うなら、コードで管理したほうが間違いが減ります。

料金と制限

WAF は、プランによって使えるルールセットとカスタムルールの本数が変わります。次の表は 2026年9月時点の目安です。

個人のブログや小さなサイトなら、Free の5本でも「管理画面の国の制限」「ログインへの確認」くらいは十分に書けます。一方、よく使われるソフトの脆弱性を広く止めたいなら、Cloudflare Managed Ruleset が使える Pro 以上が目安になります。

ほかにも、盗まれた ID とパスワードの組み合わせでのログインを見つける機能や、ファイルのアップロードの中身を調べる機能など、WAF の周りにはプランや追加契約で使える機能があります。

本数や機能の範囲は見直されることがあります。導入のときは、公式の料金ページとドキュメントで最新の内容を確かめてください。

よくある落とし穴

いちばん大事なのは3つ目です。WAF は、アプリの穴を直すまでの時間稼ぎであり、アプリの穴そのものを無くすものではありません。攻撃者は、WAF のルールに当たらない書き方を探し続けています。WAF とアプリの修正は、どちらか一方ではなく、両方でやるものです。

他の号とのつながり

エッジの中の守りは、それぞれ見ているものが違います。

この号で覚えたルールの言葉は、06号のレート制限、07号のボットのルール、09号のリダイレクトや書き換えのルールでも、そのまま使えます。

WAF がどのリクエストを止めたかは Security Events で見られますが、長期の分析やログの保存は 32号（分析とログ）で扱います。また、ルールをコードで管理する方法は 34号（Wrangler と Terraform）で扱います。