WAF とは

WAF (Web Application Firewall) は、Web アプリケーションへの HTTP/HTTPS トラフィックを検査し、悪意のあるリクエストを検知・遮断するセキュリティ製品です。従来のファイアウォールがネットワーク層 (L3/L4) で IP アドレスやポート番号を制御するのに対し、WAF はアプリケーション層 (L7) で HTTP リクエストの中身を解析します。

得意分野は、XSS、SQL インジェクション、ディレクトリトラバーサルのように、リクエストの構文そのものに攻撃の痕跡が現れる攻撃です。OWASP Top 10 の 2025 年版でいえば、インジェクション (A05:2025) の一部がこれに当たります。一方、首位に置かれたアクセス制御の不備 (A01:2025) や設計上の欠陥 (A06:2025) のように、リクエスト 1 本を見ただけでは正常と区別できない問題は WAF では判定できません。CSRF もリクエスト自体は正常に見えるため、トークン検証などアプリケーション側の対策が主となり、WAF は補助にとどまります。WAF はあくまで「緩和策」であり、アプリケーション自体の脆弱性を修正する代替にはなりません。

WAF の検知方式

シグネチャベース (ブラックリスト方式): 既知の攻撃パターン (シグネチャ) と照合して検知する方式。SELECT * FROM や <script> などの文字列パターンをリクエスト内で検出する。既知の攻撃に対して高い検知率を持つが、未知の攻撃やシグネチャを回避する難読化手法には弱い。
ホワイトリスト方式: 正常なリクエストのパターンを定義し、それ以外をすべてブロックする方式。未知の攻撃にも対応できるが、正常なリクエストの定義が不完全だと誤検知 (False Positive) が多発する。API のように入力形式が厳密に定義されている場合に有効。
スコアリング方式: 複数のルールに対する違反度をスコアとして加算し、閾値を超えたリクエストをブロックする。単一のルールでは判定が難しいグレーゾーンの攻撃に対して柔軟に対応できる。OWASP Core Rule Set (CRS) の Anomaly Scoring Mode がこの方式で、個々のルールは検知とスコア加算だけを担い、遮断するかどうかはすべてのルールを評価した後にまとめて判断される。
機械学習ベース: 正常なトラフィックパターンを学習し、逸脱するリクエストを異常として検知する。未知の攻撃に対応できる可能性があるが、学習データの品質に依存し、誤検知の調整が難しい。

WAF の導入形態

WAF は導入形態によって 3 つに分類されます。

クラウド型 WAF: 事業者側のネットワークでリクエストを受けてから配信元へ転送する方式。DNS をリバースプロキシに向ける形 (Cloudflare の WAF など) と、CDN やロードバランサーに WAF を関連付ける形 (AWS WAF など) がある。専用ハードウェアを購入せずに始められ、DDoS 攻撃対策と組み合わせて提供されることが多い。
アプライアンス型: 専用ハードウェアをネットワーク上に設置する方式。高いスループットと細かなカスタマイズが可能だが、初期費用が高く、運用に専門知識が必要。大規模企業向け。
ソフトウェア型 (ホスト型): Web サーバーにモジュールとしてインストールする方式。OWASP が管理する ModSecurity が代表的で、2026 年 8 月時点も Apache License 2.0 のオープンソースとして開発が続いている。無償で使えるが、ルールの作成・チューニングに高い専門性が求められる。

小規模サイトにはクラウド型、大規模で細かな制御が必要な環境にはアプライアンス型が適しています。すでに CDN やロードバランサーを経由している構成なら、そこに WAF を関連付ける形で配信元サーバーに手を入れずに適用できますが、適用後の誤検知の切り分けとルール調整の手間は変わらず残ります。

WAF 運用の実践ポイント

WAF は「導入して終わり」ではなく、継続的なチューニングが不可欠です。

誤検知の管理: WAF の最大の運用課題は誤検知です。正常なリクエストがブロックされると、ユーザー体験を直接損ないます。導入初期はブロックモードではなく検知モード (ログのみ) で運用し、誤検知パターンを把握してからブロックに切り替えてください。
ルールの定期更新: 攻撃手法は日々進化するため、マネージドルールセットを利用している場合でも、新しいルールの追加や既存ルールの有効性を定期的に確認する必要があります。
仮想パッチとしての利用: 修正版の提供や自社での改修が間に合わない期間だけ、その脆弱性を突くリクエストを WAF で止める使い方です。ゼロデイ攻撃への初動としても使われますが、恒久修正までの時間稼ぎであり、攻撃リクエストの書き方が変えられればすり抜けます。修正そのものを置き換えるものではありません。
ログ分析: WAF のログはセキュリティインシデントの調査に不可欠です。ブロックされたリクエストのパターンを分析し、攻撃の傾向を把握してください。
CSP との併用: WAF がサーバー側でリクエストをフィルタリングするのに対し、CSP はブラウザ側でスクリプトの実行を制限します。両者を組み合わせることで、XSS に対する多層防御が実現します。

WAF はアプリケーションの脆弱性を根本的に修正するものではありません。WAF に頼りきるのではなく、セキュアコーディング、入力バリデーション、パラメータ化クエリなど、アプリケーション側の対策と併用することが重要です。

よくある誤解

WAF を導入すれば Web アプリケーションの脆弱性対策は完了: WAF は既知の攻撃パターンを緩和しますが、アプリケーション自体の脆弱性は残ったままです。WAF のルールを回避する手法も存在するため、根本的な脆弱性修正とセキュアコーディングが不可欠です。
WAF はすべての Web 攻撃を防げる: ビジネスロジックの悪用 (不正な値引き操作、権限昇格など) や、認証情報の窃取 (フィッシング) など、正常なリクエストと区別がつかない攻撃は WAF では検知できません。WAF が得意なのは SQL インジェクションや XSS のような構文的に異常なリクエストの検知です。

クラウド型 WAF とアプライアンス型 WAF の比較

クラウド型 WAF

DNS の切り替えや CDN・ロードバランサーへの関連付けで導入できる。専用ハードウェアが不要で初期費用を抑えやすく、DDoS 対策と組み合わせて提供されることが多い。マネージドルールで運用負荷が低い。ただしカスタマイズの自由度はベンダーに依存し、トラフィック量に応じた従量課金でコストが増加する場合がある。

アプライアンス型 WAF

自社ネットワーク内に設置。高スループットと細かなルールカスタマイズが可能。ただし初期費用が高く、ルール作成・チューニングに専門知識が必要。ハードウェアの保守・更新も自社で対応する必要がある。

WAF (Web アプリケーションファイアウォール)