WAFとは？仕組み・種類・無料で始める導入方法と確認手順

サーバー公開 2026-10-13　/　最終確認 2026-10-13　/　執筆・監修中澤祐樹

WAF（Web Application Firewall、ウェブアプリケーションファイアウォール）とは、Web サイトと利用者のあいだでやり取りされる HTTP 通信の中身を検査し、SQL インジェクションやクロスサイトスクリプティング（XSS）のような Web アプリケーションへの攻撃を検知・遮断する仕組みです。IPA（情報処理推進機構）は、WAF を「脆弱性を修正するといった根本的な対策ではなく、攻撃による影響を低減する対策」と位置づけています。

つまり WAF は、入れれば安全になる魔法の箱ではなく、脆弱性の修正やソフトウェアの更新を補うもう一枚の防御です。しかも、検査は機械的に行われるため、正常なアクセスを誤って止める「誤検知」も起こります。最初は「検知だけ」で始めてログを確認し、問題がなければ遮断に切り替えるのが基本の進め方です。

この記事では、WAF の仕組みとファイアウォールとの違い、防げるもの・防げないもの、クラウド型・ホスト型などの種類、無料で始められる選択肢、設定例つきの導入手順、導入後の確認方法を順に説明します。あわせて、サイトスカウターの「サーバー情報調査」で WAF について分かること・分からないことも、コードで確認できた範囲で正直に書きます。

1. WAFとは？ファイアウォール・IPSとの違い 2. WAFで防げる攻撃・防げない攻撃と、導入が向く場面 3. WAFの種類：クラウド型・ホスト型・ネットワーク型の違い 4. WAFの検知方式とルール：誤検知はなぜ起きるか 5. WAFの導入方法：検知モードから始める手順 6. 無料で始められるWAFの選択肢と注意点 7. WAF導入後の確認方法：動作テストとログの見方 8. サイトスカウターのサーバー情報調査でWAFは分かる？ 9. WAF導入のチェックリストとよくある失敗よくある質問出典・参考資料

WAFとは？ファイアウォール・IPSとの違い

OWASP（Web アプリケーションのセキュリティを扱う非営利の国際コミュニティ）は、WAF を「HTTP アプリケーションのためのアプリケーションファイアウォール」と説明しています。HTTP のやり取りに一連のルールを適用するもので、そのルールは一般に、クロスサイトスクリプティングや SQL インジェクションのような一般的な攻撃を対象にします。一般的なプロキシが利用者（クライアント）を守るのに対し、WAF はサーバーを守る側の仕組みだとも説明されています。

通常のファイアウォール（FW）との違い

IPA の「Web Application Firewall 読本」は、名前に「ファイアウォール」と付いていても、WAF と FW は機能が異なると説明しています。FW は送信元・送信先の情報（IP アドレスやポート番号など）でアクセスを制限します。ところが Web サイトは、不特定多数に公開するために通信を許可しておく必要があり、FW だけでは Web アプリケーションの脆弱性を悪用する攻撃は防げません。WAF は、FW を通過したあとの通信の中身（リクエストライン、ヘッダー、POST データなど）を検査します。

IPS との違い

IPS（侵入防止システム）も検出パターンで通信の中身を検査しますが、同資料によれば、IPS は OS の脆弱性やファイル共有サービスへの攻撃など、さまざまな種類の機器への通信を対象にするのに対し、WAF はWeb アプリケーションへの攻撃に特化しています。そのため WAF では、既知の攻撃パターンを並べる検査に加えて、正常な通信を定義して外れたものを止める検査も使えるのが特徴です。

WAF に期待できる効果

同資料が挙げる効果は、脆弱性を悪用した攻撃から Web アプリケーションを防御する、そのような攻撃を検出する、複数の Web アプリケーションへの攻撃をまとめて防御する、の 3 つです。クレジットカード番号のように特徴のある個人情報のパターンを設定して、悪意のある相手へ送信されるのを防ぐ使い方もできると説明されています。

WAFで防げる攻撃・防げない攻撃と、導入が向く場面

IPA の資料は、WAF を導入してもすべての脆弱性を悪用した攻撃を防げるわけではないと明記しています。理由は 2 つあります。

通信が「正常」に見える脆弱性：たとえば認可制御の不備で、特定の利用者にだけ許すはずの機能がほかの利用者にも使えてしまう場合、HTTP 通信そのものは WAF にとって正常な通信と判定されてしまいます。
検査の誤り（偽陰性・偽陽性）：機械的な検査なので、不正な通信を見逃す「偽陰性」と、正常な通信を不正と判定して止める「偽陽性」の両方が起こりえます。偽陽性が起こると、利用者の正当な操作が止まり、サイトの可用性が下がる可能性があります。

WAF の導入が有効とされる場面

同資料は、脆弱性を修正することが最も望ましい対応だとしたうえで、次のような場面では WAF が有効な場合があると整理しています。

開発者や運営者が異なる複数の Web アプリケーションに、同じ対策を実施したい
開発元が撤退している、サポートが終了している、改修費用が出せないなど、脆弱性をすぐに修正できない
攻撃を受けている最中で、修正までの間、すぐに攻撃を防御する必要がある

逆にいえば、自分で修正できるコードの脆弱性や、更新すれば直る CMS・プラグインの脆弱性は、まず修正・更新するのが先です。脆弱性そのものの種類と見つけ方は脆弱性診断の記事で解説しています。

図1　WAF が得意なこと・難しいこと

出典：IPA「Web Application Firewall 読本」の記述をもとに整理。

WAFの種類：クラウド型・ホスト型・ネットワーク型の違い

IPA の読本は、WAF を置く場所を「ネットワーク」と「ウェブサーバー」の 2 つに分け、さらに企業や組織が WAF をサービスとして提供しているものもあると説明しています。本記事では分かりやすさのため、サービスとして使うものを「クラウド型」と呼び、3 つに整理します（「クラウド型」は IPA の用語ではなく、一般的な呼び方です。IPA の資料では、サーバーに入れるタイプは「ホスト型 WAF」と呼ばれることもあるとされています）。

種類	置き場所	特徴（IPA の説明より）
クラウド型（サービス）	利用者とサイトの通信経路上	自分のネットワークに設置する必要がなく、サーバーやネットワーク構成への影響が小さい
ホスト型	Web サーバー自体	サーバーの動作環境に依存し、サイトを構成するサーバーすべてに導入する。ネットワーク構成の見直しは不要。HTTPS はサーバー側で復号されるため検査できる。サーバーの性能が下がる可能性がある
ネットワーク型	ネットワーク上の専用機器など	サーバーの環境や台数に依存しない。既存サイトに入れるときはネットワーク構成の見直しが必要で、HTTPS の検査には WAF 側の対応が要る。サイトの可用性が下がる可能性がある

どれを選ぶか

レンタルサーバーや小規模サイトでは、サーバーに自由にソフトを入れられないことが多く、実際の選択肢は「クラウド型のサービスを使う」か「契約中のサーバーが標準で用意している WAF 機能を使う」になりがちです。自分でサーバーを管理している場合は、ホスト型（ModSecurity など）も選べます。いずれの型でも、WAF が利用者とサーバーのあいだに入る以上、設定を誤るとサイトが開けなくなる可能性があることは同じです。

図2　WAF の種類の選び方

WAFの検知方式とルール：誤検知はなぜ起きるか

ブラックリスト方式とホワイトリスト方式

IPA の資料では、WAF の検出パターンの定義方法を 2 つに分けています。

ブラックリスト：「不正な値やパターン」を定義して検出する方式。既知の攻撃を防げますが、すでに特徴が分かっている攻撃しか検出できないため、新しい手口が判明するたびに更新が必要です。どの Web アプリケーションにも同じものを使えますが、すべてのパターンを有効にすると偽陽性が起こることがあります。
ホワイトリスト：「正しい値やパターン」を定義して、外れたものを止める方式。Web アプリケーションの設計に基づいて作るため、アプリごとに作成が必要で、仕様を変えたら更新も要ります。自由入力のフォームは「正しい値」を決めにくく、検出パターンを作れない場合もあります。

点数方式（アノマリースコア）の例：OWASP CRS

オープンソースの代表的なルール集に、OWASP が管理する Core Rule Set（CRS）があります。ModSecurity や、互換のある WAF エンジン（Coraza など）向けの汎用的な攻撃検知ルールで、SQL インジェクション、XSS、ファイル読み込み系の攻撃、コマンド実行系の攻撃などを対象にします。

CRS の公式ドキュメントによると、ルールにマッチするたびに通信へ「異常度」の点数が加算され、リクエストの検査がすべて終わった時点で合計が基準値（既定は 5）以上なら遮断されます。重大度が CRITICAL のルールは 5 点なので、既定では 1 つ当たっただけで遮断になる計算です。公式ドキュメントは、基準値を上げると検知が鈍くなり、多くの攻撃がすり抜けるおそれがあるとして、既定値の維持を勧めています。誤検知が出たときは、全体の基準値を上げるよりも、問題のルールだけを調整・除外するのが一般的な進め方です。

検出したあとの処理

IPA の資料では、WAF が不正と判定した通信への処理を 3 つに分けています。通過処理（そのまま通して記録だけ行う。導入時の検証に使う）、エラー処理（WAF が 403 などのエラー応答を返す）、遮断処理（通信を破棄する）です。導入直後は通過処理（検知のみ）で始めるのが、この設計の使いどころです。

WAFの導入方法：検知モードから始める手順

IPA の読本は、導入を「導入判断」「導入」「運用」の 3 工程に分けています。導入の検証では、まずテスト環境で動作を確かめ、次に本番環境へ入れて通過処理（通信に影響を与えない状態）でログを確認する「テスト運用」を行い、問題がなければ本番運用に進む流れです。これは現在のクラウド型サービスでも、考え方としてそのまま使えます。

共通の手順

守る対象（ドメイン、管理画面、決済・会員ページなど）と、サーバー構成を書き出す
種類を選ぶ（前の章参照）
可能ならテスト環境で、導入手順そのものを検証する
本番には「検知のみ（ログ・カウントのみ）」で入れ、数日〜数週間のログを確認する
正常なアクセスが検知されていたら、そのルールだけを除外・調整する
誤検知が落ち着いたら、遮断に切り替える

クラウド型の例：Cloudflare WAF

Cloudflare の公式ドキュメントによると、WAF を使うには Cloudflare のアカウントにドメインを追加し、サイトへの通信が Cloudflare のネットワークを経由する状態にする必要があります。Free プランでは、Cloudflare Managed Ruleset の一部である「Free Managed Ruleset」が既定で有効になり、有料プランでは管理ルールセットを手動で有効にします。Cloudflare 版の OWASP Core Ruleset は Pro 以上で使えますが、公式は「誤検知が起きやすい」と注意しています。効果の確認は、ダッシュボードの Security Analytics・Security Events で、ブロックされた通信と誤検知を見て行います。

クラウド型の例：AWS WAF

AWS WAF は、Amazon CloudFront、Application Load Balancer、Amazon API Gateway などの AWS のリソースに付ける WAF です。AWS の公式ドキュメントは、本番トラフィックに適用する前に、ステージング環境で調整し、さらにCount（カウント）モードで本番のトラフィックを見てからルールを有効にするよう勧めています。利用できるのは、対象のリソースが AWS 上にある場合です。

ホスト型の例：Apache + ModSecurity + OWASP CRS

自分で管理するサーバーなら、ModSecurity に CRS を組み合わせられます。CRS の公式手順では、ルールを展開して crs-setup.conf.example を crs-setup.conf に名前変更し、Apache の設定に次の行を加えます（展開先を /etc/crs4 とした例）。

# ModSecurity 本体の設定で、まず検知のみにする
SecRuleEngine DetectionOnly

# OWASP CRS を読み込む
IncludeOptional /etc/crs4/crs-setup.conf
IncludeOptional /etc/crs4/plugins/*-config.conf
IncludeOptional /etc/crs4/plugins/*-before.conf
IncludeOptional /etc/crs4/rules/*.conf
IncludeOptional /etc/crs4/plugins/*-after.conf

SecRuleEngine DetectionOnly は、ModSecurity の公式の推奨設定ファイル（modsecurity.conf-recommended）でも既定になっている「検知のみ」の設定です。ログを確認して誤検知を潰したら、SecRuleEngine On に変えて遮断を有効にします。CRS の公式ドキュメントも、遮断を有効にする前に十分にテストし、まず検知のみで誤検知を洗い出すよう勧めています。ModSecurity 本体のインストールとサーバーソフトへの組み込み方は環境ごとに異なるため、ここでは省略します。

図3　WAF 導入の進め方

いきなり遮断にせず、検知のみで様子を見るのが基本です。

無料で始められるWAFの選択肢と注意点

費用をかけずに WAF を試す方法は、主に次の 3 つです。

Cloudflare の Free プラン：Free Managed Ruleset は、公式ドキュメントによれば全プランで利用でき、広く悪用されている脆弱性への対策を目的にしたルールです。ただし Cloudflare Managed Ruleset の一部のみで、フルセットは Pro 以上で使います。
オープンソースの WAF エンジンとルール：ModSecurity と OWASP CRS はオープンソースで提供されています。ソフトウェア自体に費用はかかりませんが、導入・ログ確認・ルール更新はすべて自分で行います。
レンタルサーバーなどの標準機能：契約中のサーバーに WAF 機能が付いていることがあります。有無・対象・設定方法は事業者ごとに異なるため、契約先の公式案内で確認してください。

「無料」の落とし穴

IPA の読本は、WAF の運用費用として、ログの確認、WAF 自身の更新、検出パターンの更新にかかる人件費などを挙げています。無料で入れられても、ログを見て誤検知を調整する手間は、費用として別にかかります。「入れたまま放置」にすると、新しい手口に追随できなかったり、正常な通信を止め続けたりします。個人サイトでも、「導入直後の数週間は頻繁にログを見る」「その後も定期的に見直す」といった運用を決めておくと安心です。

なお、AWS WAF など従量課金のサービスについては、料金体系が変わることがあるため、ここでは金額に触れません。検討する際は各社の公式の料金ページを確認してください。

WAF導入後の確認方法：動作テストとログの見方

1. 自分のサイトで検知されることを確認する

CRS の公式ドキュメントは、導入の確認用に次のようなリクエストを示しています。攻撃の文字列に見える値をクエリに付けるだけの、動作確認用のものです。

curl 'https://www.example.com/?foo=/etc/passwd&bar=/bin/sh'

検知のみの状態なら、通常どおり応答が返り、WAF のログ（ModSecurity なら監査ログ、Cloudflare なら Security Events、AWS WAF ならログまたは Count の結果）に検知の記録が残ります。遮断を有効にしたあとは、403 などのエラー応答になるのが想定どおりの動きです。

この確認は、必ず自分が管理するサイトに対してだけ行ってください。他人のサイトに攻撃を模した通信を送ると、不正アクセスなどの問題につながるおそれがあります。詳しくは脆弱性診断の記事を参照してください。

2. 正常な操作が止まっていないか確認する

偽陽性は、利用者の正当な操作を止めます。IPA の資料も、監査ログの定期的な確認で偽陽性の有無を見るよう勧めています。お問い合わせフォーム、会員登録・ログイン、決済、管理画面の投稿画面など、入力が多い画面を実際に操作して、エラーにならないかを確かめてください。長い文章、記号、URL を含む入力は、検知の対象になりやすい入力です。

3. 運用の見直し

ログを定期的に確認する（偽陽性と、検知された攻撃の傾向）
WAF のアップデートと検出パターンの更新を、運用手順に入れておく
パターン更新によって正常な通信が一時的に止まることがあるため、更新後の動作確認も手順に含める
Web アプリケーション本体の仕様を変えたら、特にホワイトリスト方式では調整が必要になる

サイトスカウターのサーバー情報調査でWAFは分かる？

結論からいうと、サイトスカウターのサーバー情報調査には、WAF を検出・判定する機能はありません。実装を確認したところ、WAF の有無や製品名を推定する処理はなく、結果画面に「WAF あり／なし」とは表示されません。

代わりに、次のような項目が確認できます。

HTTP ステータスと最終 URL：調査は、サイトへの HTTP GET を 1 回行います。WAF などがこの調査のアクセスを拒否した場合は、ステータスに表れる可能性があります（調査用の User-Agent は SiteScouterBot と名乗ります）。
HTTP レスポンスヘッダーの一覧：返ってきたヘッダーが、名前と値（長いものは 300 文字まで）で一覧表示されます。導入したサービスが独自のヘッダーを付ける場合は、目視で確認する手がかりになりますが、ヘッダーの有無だけでは WAF が有効に働いているかは分かりません。
セキュリティヘッダー：Strict-Transport-Security、Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy の有無を判定します。WAF とは別に、サーバー側で設定するもう一つの守りです。セキュリティヘッダーの記事とHSTS の記事で設定方法を解説しています。
Cookie の属性、バージョン情報の露出：Secure・HttpOnly・SameSite の不足や、Server・X-Powered-By ヘッダーにバージョン番号が出ていないかを警告します。
HTTPS・証明書、ブラックリスト登録：証明書の期限や認証レベル、DNSBL の登録状況なども確認できます。

WAF が実際に攻撃を止められるかどうかは、攻撃を模した通信を送らないと確かめられません。サイトスカウターは第三者のサーバーへの影響を避けるため、DNS 照会・WHOIS・TLS ハンドシェイク 1 回・HTTP GET 1 回の非侵襲な範囲に限っており、そうしたテストは行いません。WAF の効き具合は、前の章のとおり、自分のサイトで WAF のログを使って確認してください。

図4　/server/ で見えること・見えないこと

WAF導入のチェックリストとよくある失敗

最後に、導入時にありがちな失敗をまとめます。

WAF を入れたから脆弱性を直さなくてよいと考える。WAF は根本対策ではなく影響を低減する対策です。CMS・プラグイン・ライブラリの更新と、アプリの修正を先に進めます。
最初から遮断モードにする。誤検知で、問い合わせフォームや決済が止まる事故につながります。検知のみで始めます。
ログを見ない。誤検知も、実際の攻撃の傾向も、ログを見ないと分かりません。
基準値やルールを雑にゆるめる。CRS では、点数の基準値を上げると攻撃がすり抜けやすくなります。個別のルールだけを調整します。
ほかの対策を忘れる。HTTPS 化、セキュリティヘッダー、強いパスワードと二要素認証、バックアップは、WAF では代替できません。
例外設定を放置する。誤検知を避けるために開けた例外が、そのまま残らないよう、設定を定期的に見直します。

WAF は、導入してからが運用のスタートです。検知のみで始め、ログで確かめ、遮断に進み、定期的に見直す。この流れを守れば、小さなサイトでも無理なく続けられます。

サイトスカウターで調べる

WAF を入れたあとのサイトが、HTTPS やセキュリティヘッダー、応答ヘッダーの面でどう見えているかは、サーバー情報調査に URL を入れると確認できます（WAF の有無そのものは判定しません）。

サーバー情報調査を使う

よくある質問

WAFとは何ですか？

Web サイトと利用者のあいだの HTTP 通信の中身を検査し、SQL インジェクションやクロスサイトスクリプティングなど、Web アプリケーションへの攻撃を検知・遮断する仕組みです。IPA は、脆弱性の修正のような根本的な対策ではなく、攻撃による影響を低減する対策と位置づけています。

WAFを入れれば脆弱性対策は不要ですか？

不要にはなりません。IPA の資料は、WAF を導入してもすべての攻撃を防げるわけではないと説明しています。たとえば認可制御の不備は、通信自体が正常に見えるため WAF では防げません。脆弱性の修正やソフトウェアの更新を優先し、WAF は補う対策として使います。

WAFは無料で使えますか？

無料で始められる選択肢はあります。Cloudflare の Free Managed Ruleset は全プランで利用でき、ModSecurity と OWASP CRS もオープンソースです。ただし、ログの確認や誤検知の調整といった運用の手間は別にかかります。サービスの料金や機能は変わるため、公式の最新情報を確認してください。

WAFが正常なアクセスを止めてしまったらどうしますか？

WAF のログで、どのルールが反応したかを確認し、そのルールだけを除外または調整します。点数方式の CRS では、全体の基準値を上げるのではなく個別のルールを調整するのが一般的です。導入時に検知のみで始めておけば、遮断に切り替える前にこうした誤検知を見つけられます。

サイトスカウターでWAFが入っているか分かりますか？

WAF の有無を判定する機能はありません。サーバー情報調査では、HTTP ステータスや応答ヘッダーの一覧、セキュリティヘッダー、HTTPS・証明書などを確認できます。

出典・参考資料

最終確認日：2026-10-13。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。

本記事は一般的な情報提供を目的としており、法的助言ではありません。被害に遭われた場合や判断に迷う場合は、消費者ホットライン（188）や警察相談専用電話（#9110）などの公的窓口にご相談ください。