前のページでは、大量のアクセスでサービスを停止させるDDoS攻撃を学びました。しかしWebサイトへの攻撃は「量」で押し切るものばかりではありません。たった1回のリクエストでデータベースの中身を盗み出したり、サイトを改ざんしたりする、「質」で攻めてくる攻撃があります。それを防ぐのがWAFです。
WAFは、Cloudflareに限らずWebセキュリティの世界で必ず登場する基本用語です。このページでは、WAFが何を防ぐ仕組みなのかを具体的な攻撃例から理解し、そのうえでCloudflare WAFの構成を見ていきます。
このページで分かること
- WAF（Webアプリケーションファイアウォール）とは何か
- WAFが防ぐ代表的な攻撃（SQLインジェクション・XSSなど）
- 通常のファイアウォールとWAFの違い
- Cloudflare WAFの構成（マネージドルールとカスタムルール）
- プランによる違いと、初心者が注意するポイント
WAFとは
アプリケーションを狙う攻撃
WAF（Web Application Firewall：Webアプリケーションファイアウォール）は、Webサイトやアプリケーションに届くHTTPリクエストの中身を検査し、攻撃の特徴を持つリクエストをブロックする仕組みです。
「アプリケーションを狙う攻撃」とはどういうものか、代表例を2つ見てみましょう。
SQLインジェクションは、入力欄にデータベースへの命令文（SQL）を紛れ込ませる攻撃です。たとえばログイン画面のユーザー名欄に ' OR '1'='1 のような文字列を入力すると、作りの甘いプログラムでは「条件は常に真」と解釈され、パスワードなしでログインできてしまったり、会員情報をまるごと抜き出されたりします。大規模な個人情報漏えい事件の多くはこの手口によるものです。
XSS（クロスサイトスクリプティング）は、掲示板やコメント欄などに悪意あるスクリプト（ブラウザーで動くプログラム）を書き込み、そのページを開いた他の訪問者のブラウザーで実行させる攻撃です。偽のログイン画面を表示させたり、ログイン状態を示す情報（Cookie）を盗んだりするのに使われます。
いずれも、リクエストは1回で足り、見た目は通常のフォーム送信と同じ形をしています。DDoSのような「異常な量」がないため、量の監視では検知できません。中身を読んで「この入力は攻撃だ」と判断する仕組み、それがWAFです。
通常のファイアウォールとの違い
「ファイアウォール」という言葉自体は聞いたことがあると思います。従来のファイアウォールは、通信の宛先ポートや送信元IPアドレスといった「封筒の宛名」を見て通す・通さないを判断します。たとえば「Web用の443番ポート以外は閉じる」といった制御です。
しかしWebサイトを公開する以上、443番ポートは開けておくしかありません。攻撃者はその正規の入り口から、正規のHTTPリクエストの形で攻撃を送り込んできます。封筒の宛名は完全に正常なので、従来のファイアウォールでは素通りです。WAFは封筒を開けて「手紙の中身」（URL・ヘッダー・フォームの入力値など）まで読み、攻撃の特徴を検査する点が違います。
なぜサーバー側の対策だけでは足りないのか
本来、SQLインジェクションもXSSも、アプリケーション側を正しく作れば防げる攻撃です。それでもWAFが必要とされるのには理由があります。
- 自分で書いたプログラムに見落としがないとは言い切れない
- WordPressのようなCMSやプラグインの脆弱性（セキュリティ上の欠陥）は日々発見され、修正が公開される前に攻撃が始まることもある（ゼロデイ攻撃）
- 修正版の適用（アップデート）までの間、無防備になる期間が生じる
WAFは、脆弱性そのものを直すわけではありませんが、攻撃が届く前の「関所」で食い止めることで時間を稼げます。脆弱性の修正が間に合わない期間をWAFのルールでしのぐことは「仮想パッチ」とも呼ばれます。
Cloudflare WAFの構成
CloudflareのWAFは、プロキシ（オレンジ雲）を通る全リクエストに対して働きます。DDoS対策と同じく、追加のソフトウェアをサーバーに入れる必要はありません。中心となるのは次の2種類のルールです。
マネージドルール：Cloudflareが管理する防御ルール集
マネージドルール（Managed Rules）は、Cloudflareの専門チームが作成・更新する攻撃検知ルールのセットです。世界中のトラフィックから観測された最新の攻撃パターンが反映され、利用者は「有効にする」だけで使えます。代表的なルールセットは次のとおりです。
- Cloudflare Managed Ruleset：Cloudflareが独自に管理する主力ルールセット。新しい脆弱性への対応が早い（Pro以上）
- OWASP Core Ruleset：Webセキュリティの標準化団体OWASPによる、業界標準のルールセットをCloudflareが調整したもの（Pro以上）
- 無料版マネージドルール（Cloudflare Free Managed Ruleset）：Freeプランでも自動で適用される縮小版。世間を騒がせた影響の大きい脆弱性への攻撃を防ぐ
WordPressを狙った攻撃への対応ルールも含まれており、WordPressサイトの運営者にとっては「プラグインの脆弱性が見つかってから更新するまでの保険」として特に価値があります。
カスタムルール：自分で書く防御ルール
カスタムルール（Custom Rules）は、利用者が自分の条件で書くルールです。リクエストの国・IPアドレス・URL・User-Agent（ブラウザーの種類を示す情報）・HTTPメソッドなどを組み合わせて条件を作り、一致したリクエストに対するアクション（ブロック、チャレンジ＝人間かどうかの確認、スキップ、ログ記録のみ）を指定します。
たとえば、次のような使い方ができます。
- WordPressの管理画面（/wp-admin/）へのアクセスを自分の国以外からブロックする
- 特定の攻撃的なUser-Agentやリクエストパターンを遮断する
- 問い合わせフォームのURLだけ、海外からのPOST（送信）にチャレンジを課す
料金プランのページで見たとおり、カスタムルールの上限はFree 5個／Pro 20個／Business 100個／Enterprise 1,000個です。5個でも工夫しだいで実用的な防御が組めます。
ルールはどう働くか
リクエストがCloudflareに届くと、DDoS対策の判定に加えて、カスタムルールやマネージドルールが順に評価されます。ルールに一致すると、指定されたアクション（ブロック等）が即座に実行され、オリジンサーバーにはリクエストが届きません。何が何件ブロックされたかは、ダッシュボードのセキュリティイベント画面でいつでも確認できます。「導入した翌日にイベントログを見たら、想像以上の攻撃が来ていて驚いた」というのは、Cloudflare導入者の定番の体験談です。
初心者が注意するポイント
- 誤検知（false positive）はあり得る：正規の操作が攻撃と誤判定されてブロックされることがあります。特に、長文の投稿やHTMLを含む入力は引っかかりやすい箇所です。問題が起きたら、セキュリティイベントでどのルールに一致したかを確認し、そのルールだけを調整・除外できます
- まずはログで様子を見る手もある：カスタムルールのアクションには「ログ記録のみ」（Log。Enterprise向け）やチャレンジがあります。いきなり全面ブロックにせず、チャレンジで様子を見るのは安全な進め方です
- WAFは万能ではない：暗号化されていても中身は検査できますが、アプリケーションの設計ミス（権限チェック漏れなど）や、正規のログイン情報を使った不正ログインは、パターン検査だけでは止めきれません。ボット対策やRate Limiting（次ページ以降）との組み合わせが大切です
- サーバー側の更新は継続する：WAFは時間を稼ぐ関所であって、脆弱性を消すものではありません。CMS・プラグインのアップデートは変わらず基本です
- オレンジ雲が前提：DDoS対策と同じく、WAFが働くのはプロキシ経由のトラフィックだけです
関連サービス
- DDoS Protection：量の攻撃を防ぐ仕組み。WAFと並ぶ防御の柱です（前ページ）
- Rate Limiting：回数ベースでアクセスを制限する機能。ブルートフォース（総当たり）対策に有効です（このあとのページ）
- ボット対策（Bot Fight Mode / Bot Management）：自動化されたアクセスそのものを見分けて対処します（次ページ）
まとめ
- WAFは、HTTPリクエストの中身を検査して、SQLインジェクションやXSSなどアプリケーションを狙う攻撃をブロックする仕組み
- 従来のファイアウォールが「封筒の宛名」を見るのに対し、WAFは「手紙の中身」まで読む
- 脆弱性の修正が間に合わない期間を守る「仮想パッチ」としての価値が大きい
- Cloudflare WAFは、Cloudflareが管理するマネージドルールと、自分で書くカスタムルールの二本柱
- Freeプランでもカスタムルール5個と無料版マネージドルールが使え、Pro以上でフル機能のルールセットが有効になる
- 誤検知はセキュリティイベントで確認・調整できる。WAFがあってもサーバー側の更新は続けること
次に読む
※本記事の情報は 2026年8月時点のものです。