はじめに
Web アプリケーションや API を公開すると、SQL インジェクションや XSS、bot による不正アクセスなど、アプリケーション層を狙った攻撃にさらされます。こうした攻撃への対策として広く使われるのが WAF（Web アプリケーションファイアウォール）です。製品やサービスを選ぶ前に、WAF が何をするもので、どんな仕組みと種類があるのかを押さえておくと、自社の環境に合った選定がしやすくなります。
- WAF の役割と、ネットワークファイアウォールや IPS との違い
- WAF が防ぐ攻撃と、OWASP Top 10 における位置づけ
- クラウド型・アプライアンス型・ホスト型の提供形態と選定の観点
WAF は、HTTP・HTTPS リクエストを L7（アプリケーション層）で検査し、SQLi や XSS などの Web アプリケーション特有の攻撃を制御する防御層です。ネットワークファイアウォールが IP アドレスやポートで通信を制御するのに対し、WAF はリクエストの中身を理解して判断します。提供形態にはクラウド型・アプライアンス型・ホスト型があり、用途に応じて選びます。本記事は、これらの基礎を中立的に整理するクラスター最上位の入り口です。具体的な製品ごとの実装は、個別の解説記事へ案内します。
WAF とは（L7 の Web アプリケーションファイアウォール）
WAF は、Web アプリケーションへの HTTP・HTTPS トラフィックを監視・フィルタリングし、不正なリクエストを遮断するセキュリティの仕組みです。クライアントとアプリケーションの間に入り、すべてのリクエストを検査してからアプリケーションへ渡す、リバースプロキシのように動作します。
参考: OWASP – Web Application Firewall
“A web application firewall （WAF） is an application firewall for HTTP applications”
（WAF は、HTTP アプリケーション向けのアプリケーションファイアウォールです）
https://owasp.org/www-community/Web_Application_Firewall
WAF は、リクエストのヘッダー、クエリ文字列、ボディなどを検査し、あらかじめ定めたルールに従って許可・遮断などを判断します。検査対象が HTTP・HTTPS に限られる点が、より広い範囲のトラフィックを扱う他のセキュリティ機器との違いになります。
ネットワークファイアウォール・IPS・RASP との違い
WAF は、他のセキュリティ機器と対象とするレイヤーや守備範囲が異なります。役割を整理すると次のようになります。
| 仕組み | 対象レイヤー | 検査対象 | 主な役割 |
|---|---|---|---|
| ネットワークファイアウォール | L3/L4 | IP アドレス・ポート・プロトコル | ネットワーク境界での通信可否の制御 |
| IPS/IDS | 主に L3/L4（一部 L7） | 複数プロトコルのトラフィック | シグネチャによる既知攻撃の検知・遮断 |
| WAF | L7 | HTTP・HTTPS リクエスト | Web アプリ特有の攻撃（SQLi・XSS 等）の検査・制御 |
| RASP | アプリ実行環境 | アプリ内部の処理 | 実行時にアプリ内部から不正な処理を検知・防止 |
ネットワークファイアウォールは IP アドレスやポートで通信を制御しますが、正規のプロトコル・ポートを使うアプリケーション層の攻撃は見分けられません。NGFW（次世代ファイアウォール）はディープパケットインスペクションやアプリケーション認識を備えますが、Web アプリ特有の攻撃すべてに最適化されているわけではありません。WAF はこの隙間を埋める、Web アプリケーションに特化した防御層です。
実際の運用では、ネットワークファイアウォールや IPS と WAF を組み合わせ、層を分けて守る構成が一般的です。WAF は他のセキュリティ機器を置き換えるものではなく、Web アプリケーションの層を補う位置づけになります。
WAF が防ぐ攻撃と OWASP Top 10
WAF が得意とするのは、リクエストの内容に攻撃コードが含まれるタイプの攻撃です。代表的なものに、SQL インジェクション、XSS（クロスサイトスクリプティング）、コマンドインジェクション、パストラバーサルなどがあります。WAF はリクエストのパラメータ・ヘッダー・ボディを検査し、攻撃に特有のパターンを検出して遮断します。
Web アプリケーションの代表的なリスクは、OWASP Top 10 として整理されています。2025 年版が最新で、2021 年版を置き換えています（2025 年 11 月に発表、最終版は 2026 年 1 月）。上位には Broken Access Control、Security Misconfiguration、新カテゴリの Software Supply Chain Failures、Cryptographic Failures、Injection が並びます。
参考: OWASP Top 10:2025 – Introduction
“Broken Access Control maintains its position at #1”
（Broken Access Control が #1 の座を維持しています）
https://owasp.org/Top10/2025/0x00_2025-Introduction/
ここで注意したいのは、WAF が OWASP Top 10 のすべてを単独でカバーするわけではない点です。WAF と各リスクの関係を整理すると次のようになります。
- Injection（SQLi・XSS など）: WAF が最も得意とする領域。入力の検査とパターンマッチで防ぎます。
- Broken Access Control: 認証要件やセッション管理の強制で一部を補完できますが、権限設計そのものはアプリケーション側の責任です。
- Cryptographic Failures: HTTPS の強制などで補完できます。
- Security Misconfiguration: WAF で直接は防げず、設定のハードニングが本筋になります。
- Software Supply Chain Failures、Insecure Design: WAF 単体では対処できず、SBOM の整備や設計段階の対策が必要です。
つまり、WAF は OWASP Top 10 のうち Injection 系を中心に補完する防御層であり、設計・実装の対策を置き換えるものではありません。WAF を入れたうえで、安全な設計・実装・設定を併用する考え方が前提になります。
WAF の検出方式
WAF がリクエストを許可するか遮断するかを判断する方式には、大きく二つの考え方があります。多くの製品は両者を組み合わせ、さらに機械学習による異常検知を加えています。
ネガティブセキュリティモデル（シグネチャ・ルールベース）
既知の攻撃パターン（シグネチャ）に一致するリクエストを遮断する方式です。SQL の構文やスクリプトタグなど、攻撃に特有の文字列を検出します。導入が比較的容易で、既知の攻撃に広く対応できますが、シグネチャの更新が前提となり、未知の攻撃には弱いという特性があります。
ポジティブセキュリティモデル（ホワイトリスト）
あらかじめ許可した正常な振る舞いだけを通し、それ以外を遮断する方式です。未知の攻撃にも強い一方、アプリケーションの正常な動作を定義する初期設定の手間が大きく、アプリの変更にあわせた維持も必要になります。ネガティブとポジティブの二つのモデルは、SANS Institute などでも WAF の基本的な分類として整理されています。
機械学習・異常検知
正常なトラフィックの傾向を学習し、そこから逸脱するリクエストを検出する方式です。シグネチャだけでは捉えにくい未知の攻撃や、bot の挙動の判別に用いられます。シグネチャベースと組み合わせることで、誤検知を抑えつつ検知の幅を広げます。
WAF の提供形態
WAF は、どこに配置してどう運用するかによって、いくつかの形態に分かれます。代表的なのは、クラウド型・アプライアンス型・ホスト型の 3 つです。
参考: Web Application Firewalls （WAF） in 2025
“There are three common WAF deployment models: network based, host based, and cloud based”
（WAF の代表的なデプロイモデルは、ネットワークベース・ホストベース・クラウドベースの 3 つです）
https://www.oligo.security/academy/web-application-firewalls-waf-in-2025-in-depth-guide
クラウド型（マネージド・SaaS）
クラウド上でサービスとして提供され、サブスクリプションや従量制で利用する形態です。導入が容易で自動的にスケールし、CDN と統合して DDoS 対策にも強いという特徴があります。マネージドで運用されるため、社内のセキュリティ運用リソースが限られる場合に向きます。一方、提供元が管理する範囲に設定が制約される面もあります。
クラウド型のマネージド WAF の具体例として、AWS のサービスは関連記事『AWS WAF の構成と設計の基礎｜保護対象・ルール・料金の全体像』で詳しく扱っています。
アプライアンス型（ハードウェア・仮想）
専用のハードウェアアプライアンス、または仮想アプライアンスとして、ネットワークインフラ内に配置する形態です。細かい制御が可能で、低レイテンシやデータ主権・コンプライアンス要件に対応しやすい一方、機器の調達・構築や運用の手間がかかります。Fortinet の FortiWeb や F5 の BIG-IP などがこの形態に該当します（FortiWeb の詳細は今後の関連記事で扱う予定です）。
ホスト型（ソフトウェア）
Web サーバーにソフトウェアやモジュールとして組み込む形態です。アプリケーションに密着した柔軟なカスタマイズができ、オープンソースの選択肢もあります。代表例はオープンソースの ModSecurity です。サーバーのリソースを消費し、運用・保守の負荷がかかる点には注意が必要です。
| 提供形態 | 導入・運用 | スケール | 制御の細かさ | 代表例 |
|---|---|---|---|---|
| クラウド型 | 迅速、マネージドで負荷が低い | 自動スケール | 中（マネージドの範囲） | AWS WAF、Cloudflare WAF |
| アプライアンス型 | 調達・構築が必要 | 機器の増設で対応 | 高（細かく制御可能） | FortiWeb、F5 BIG-IP |
| ホスト型 | サーバーへ組み込み | サーバーに依存 | 高（カスタマイズ可能） | ModSecurity |
WAF の選定ポイント
提供形態や製品を選ぶときは、自社の環境と運用体制に照らして判断します。主な観点を整理します。
- 保護対象の場所: 保護したいアプリケーションがクラウドかオンプレミスか、CDN と統合したいかで、適した提供形態が変わります。
- 運用負荷: マネージドに任せたいか、自分で細かく制御したいか。社内のセキュリティ運用リソースとあわせて判断します。
- 検出方式: シグネチャの更新頻度、機械学習への対応、OWASP のコアルールセット（CRS）への対応状況。
- 料金モデル: 従量制・サブスクリプション・アプライアンス購入など、トラフィック量と予算に合うモデルか。
- 誤検知への対応: ルールをいったん遮断せず記録だけする運用（カウントモードに相当）や、チューニングのしやすさ。
- コンプライアンス: PCI DSS 4.0 では、要件 6.4.2 で公開 Web アプリケーションに対する自動化された技術的対策として WAF が挙げられています。該当する基準がある場合は要件との整合を確認します。
保護対象がクラウド中心であればクラウド型、オンプレミスで細かい制御や低レイテンシが求められるならアプライアンス型、といった形で、環境に合わせて選ぶのが基本になります。
まとめ
本記事では、WAF の役割・仕組み・提供形態・選定の観点を、製品選定の起点として中立的に整理しました。WAF は HTTP・HTTPS リクエストを L7 で検査し、SQLi や XSS などの Web アプリケーション特有の攻撃を制御する防御層です。OWASP Top 10 の一部を補完しますが、安全な設計・実装と併用することが前提になります。
- WAF は L7 で HTTP・HTTPS リクエストを検査する防御層
- ネットワークファイアウォールや IPS とは対象レイヤーが異なる
- WAF が得意とするのは Injection 系（SQLi・XSS など）
- OWASP Top 10 の全体は WAF 単体ではカバーできない
- 検出はネガティブとポジティブの両モデルと異常検知の組み合わせ
- 提供形態はクラウド型・アプライアンス型・ホスト型の 3 つ
- 選定は保護対象の場所・運用負荷・料金モデルで判断
以上、最後までお読みいただきありがとうございました。
