WAF（Web Application Firewall）入門

入門 | 10分 で読める | 2026.05.02

公式ドキュメント
SecurityNetwork

WAFとは

Browserから届くRequestをWAFがWeb App手前で検査し、正常Requestを通過させ、悪性と判定したRequestを遮断する図

WAF（Web Application Firewall）は、Webアプリケーションの手前でHTTPリクエストを検査し、ルールに一致した通信を記録、制限、遮断する仕組みです。

SQLインジェクションや既知の攻撃パターンを早く止める防御の一層として役立ちます。ただし、アプリケーションの脆弱性そのものを修正する装置ではありません。

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

観点ネットワークファイアウォールWAF
主な検査対象IPアドレス、ポート、プロトコルURL、ヘッダー、Cookie、クエリ、本文
主な層L3/L4HTTPを扱うL7
代表的な判断443番ポートへの接続を許可/loginへの不審な入力を検出
配置ネットワーク境界WebアプリやAPIの手前

Web攻撃は、許可されている443番ポートへ通常のHTTPSとして届きます。ネットワーク層だけでは、入力値がSQLの断片なのか、通常の検索語なのかを判断できません。WAFはHTTPとして内容を解釈して補います。

HTTPSの内容を検査するには、WAFまたはその手前でTLSを終端し、復号後のHTTPを見られる構成が必要です。

WAFがリクエストを処理する流れ

flowchart LR
  A["Client"] --> B["TLS終端"]
  B --> C["WAFルール評価"]
  C -->|許可| D["Web App"]
  C -->|記録・Count| E["Log / Metrics"]
  C -->|Challenge・Block| F["拒否応答"]

WAFは、一般に次のようなルールを組み合わせます。

  • マネージドルール: ベンダーやOWASP CRSなどが提供する既知パターン
  • カスタムルール: 管理画面や特定APIなど、アプリ固有の条件
  • レート制限: 短時間の大量リクエストを制限
  • IP・地域条件: 明確な運用要件がある場合に対象を限定

アクションは即時遮断だけではありません。製品によって名称は異なりますが、まず記録だけを行うLogやCount、追加確認を求めるChallenge、通信を拒否するBlockなどがあります。

ルールは具体的な条件にする

たとえば、管理画面を保護する目的なら、「怪しい文字を含む通信をすべて拒否」のような広い条件ではなく、対象を絞ります。

対象Host: admin.example.com
対象Path: /login
対象Method: POST
条件: 同じ送信元から短時間に失敗が繰り返される
初期Action: Count
確認後Action: Challenge または一時的なBlock

この例でも、共有回線、学校や会社のプロキシ、IPv6アドレスの変化を考える必要があります。IPだけを利用者の識別子と決めつけず、アカウント単位の制限やアプリ側のログイン保護と組み合わせます。

ルールの評価順も重要です。監視ツール、決済サービスのWebhook、社内経路など、明確に確認できる通信をどう扱うか決めたうえで、一般ルールとレート制限を適用します。許可条件を広くしすぎると、その経路では後続の検査が行われないことがあります。

検出できる可能性がある攻撃

代表例は次のとおりです。

攻撃WAFが見つける手掛かり
SQLインジェクション入力中のSQL構文や符号化された既知パターン
反射型XSSURLや本文中のスクリプトに似た入力
パストラバーサル../などの不審なパス
既知製品への攻撃公開された攻撃パターンに合うリクエスト
単純なBotや総当たりリクエスト頻度、送信元、振る舞い

「検出できる可能性」と書くのは、攻撃の表現方法とアプリの仕様が多様だからです。ルールに一致しない攻撃は通過し、正常な入力が攻撃と誤判定されることもあります。

誤検知を前提に運用する

正常な通信を攻撃と判断することを誤検知（false positive）、攻撃を見逃すことを**検知漏れ（false negative）**といいます。

新しいルールをいきなり全体へBlockで適用すると、検索、フォーム送信、API連携などを止める危険があります。次の順序で導入します。

  1. 保護するURL、HTTPメソッド、利用者、正常な入力を把握する
  2. 新しいルールをLogまたはCountで動かす
  3. 一致したリクエストを調べ、攻撃と正常通信を分ける
  4. 除外は、URL・パラメータ・ルールIDなど必要な範囲だけに絞る
  5. 確信度の高い条件からBlockへ切り替える
  6. エラー率、遮断数、問い合わせを監視し、戻せるようにする

ルール全体を無効にすると、別の画面まで保護を失います。「このURLのこのパラメータだけ」のように狭く除外することが重要です。

ログで確認すること

WAFログには、調査に必要な最小限の情報を残します。

  • 時刻とリクエストID
  • 適用したルールIDとアクション
  • 対象ホスト、パス、HTTPメソッド
  • 応答コード
  • 必要に応じて送信元情報や国

一方、Cookie、認証トークン、パスワード、フォーム本文を無条件に記録すると、ログ自体が情報漏えい源になります。マスキング、保存期間、閲覧権限を設計します。

アプリケーションログと共通のリクエストIDを使うと、「WAFが止めたのか」「アプリがエラーを返したのか」を追いやすくなります。

アラートを調査する流れ

遮断数が急増したときは、「攻撃が増えた」と即断せず、次の順番で確認します。

  1. どのルール、URL、アクションが増えたか
  2. デプロイやキャンペーンなど、同時刻の正規トラフィック変化がないか
  3. 少数の送信元か、多数の利用者へ広がっているか
  4. アプリへ到達した同種リクエストが成功・失敗しているか
  5. 機密情報を除いたサンプルで、入力の特徴を確認できるか

攻撃なら対象を絞った遮断やレート制限を強化し、アプリの脆弱性も確認します。誤検知なら、全面停止ではなくルールID、URL、パラメータ単位で例外を調整します。変更した時刻、理由、期限、担当者を記録し、応急の例外が残り続けないようにします。

WAFのダッシュボード上の件数だけでなく、アプリの5xx率、認証失敗率、売上やフォーム完了数なども合わせて見ると、防御と業務影響の両方を判断できます。

ルール更新を本番へ反映する前に、代表的な正常リクエストと既知の不正入力を検証環境で再生できると安全です。個人情報を含む本番通信をそのまま複製せず、匿名化したテストケースとして保存します。ルールを変更したら同じケースを再実行し、守りたい攻撃を再び通していないかも確かめます。 テスト結果はルールの変更履歴と結び付けて残します。

WAFだけでは防げないもの

WAFは便利ですが、次の対策を置き換えません。

認可の不備

他人のユーザーIDを指定すると情報を読める、といった問題は、HTTPの形だけでは正常操作と区別できない場合があります。サーバー側で、操作のたびに権限を確認します。

アプリ内部やブラウザ内だけで起きる脆弱性

DOMベースXSSのように、ブラウザ上のJavaScriptだけで危険な処理が成立する場合、入口のWAFからは見えません。出力時のエスケープ、CSP、安全なDOM APIが必要です。

ビジネスロジックの悪用

クーポンの不正利用、在庫確保の繰り返し、盗まれた正規セッションによる操作は、単純な攻撃文字列を含まないことがあります。アプリ側の制約、不正検知、再認証を組み合わせます。

脆弱なコードや未更新の製品

WAFは緊急時の緩和策にはなりますが、修正プログラム、入力検証、パラメータ化クエリ、出力エンコーディングを後回しにする理由にはなりません。

導入時のチェックリスト

  • WAFが実際の利用者からアプリまでの経路上にあるか
  • HTTPSをどこで終端し、どのHTTP内容を検査できるか
  • まず記録モードで正常通信を観察したか
  • 除外条件を必要最小限にしたか
  • API、ファイルアップロード、WebSocketなども検証したか
  • 遮断増加とアプリのエラー率を監視できるか
  • 緊急時にルールを戻す手順があるか
  • ログから認証情報や個人情報を除いているか

まとめ

  • WAFはHTTPの内容を検査する、Webアプリ手前の防御層
  • マネージドルール、カスタムルール、レート制限を組み合わせる
  • 誤検知があるため、記録、確認、限定的な遮断の順で導入する
  • ログには調査情報を残し、認証情報や本文を安易に保存しない
  • WAFは、認可、入力検証、出力エンコーディング、更新を代替しない

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR