WAF は有効だが、完全な防御ではない —— Web サイトと API を守るために経営者・管理者が理解すべきこと

導入: WAF とは何か —— Web への通信を入口で検査する仕組み

WAF (Web Application Firewall) は、Web サイトや Web API に届く HTTP/HTTPS 通信を検査し、あらかじめ定めたルールに照らして、通信を通す・記録する・遮断するといった制御を行うセキュリティ機能です。Web サイトの前段に設置する「通信の検問所」と考えると分かりやすいでしょう。

要点: まず押さえるべきこと

1. WAF の防御範囲には境界がある

WAF は通信の入口で働くため、通信の内容から判断できる攻撃には効果を発揮します。一方、アプリケーション内部の処理が業務上正しいか、ログインした利用者にそのデータを見る権限があるか、サーバーやミドルウェア自体に弱点がないか、といった判断はWAF の役割ではありません。

「仮想パッチ」は恒久修正の代わりではない

WAF がミドルウェア固有の脆弱性に一切対応できない、という意味ではありません。特定の脆弱性を悪用する HTTP リクエストの特徴を識別できる場合、WAF のルールで攻撃を遮断し、修正までの時間を稼げることがあります。これは「仮想パッチ」と呼ばれる考え方です。

ただし、仮想パッチは脆弱なコードを直すものではありません。WAF が検査する通信であり、かつルールが認識できる攻撃パターンに対してのみ効果があります。攻撃方法や入力の形を変えられたり、WAF を通らない経路を使われたりすれば、保護が及ばない可能性があります。OWASP も、仮想パッチは恒久的なコード修正と並行して用い、回避可能性を検証するべきだと説明しています。[2]

したがって、WAF は「脆弱性を直さなくてもよい仕組み」ではありません。更新や改修に時間がかかる場合の一時的なリスク低減策として活用しつつ、恒久対策の期限と責任者を明確にする必要があります。

2. 正規の通信に見える攻撃は、WAF だけでは見抜きにくい

近年、Web サイトや API を標的とする攻撃では、必ずしも不正な文字列や明らかな異常リクエストを送り込むとは限りません。攻撃者が通常の会員登録やログインを行い、正規のセッションを取得したうえで、Web 画面を介さず API を直接呼び出し、許されていない情報の取得や操作を試みるケースがあります。

「サイト型攻撃」という言葉だけでは、攻撃の範囲や手法が一義的に定まりません。本記事では、こうした脅威を具体化するため、 「正規利用に見える API 悪用」 と呼びます。これは単一の攻撃手法ではなく、認証済み API の認可不備、業務フローの自動化、不正なセッション利用など、複数の問題を含みます。

例えば、どのようなことが起きるのか

1. 攻撃者が一般利用者と同じように会員登録し、ログインする。
2. 正規のログイン状態を使い、ブラウザーが通常利用時に送信する API リクエストを調べる。
3. リクエストに含まれる注文番号、会員番号、予約番号などを変更したり、通常の画面では表示されない API を直接呼び出したりする。
4. サーバー側の認可確認が不十分であれば、他人の情報を取得したり、本来許可されていない操作を実行したりできてしまう。
5. 同じ操作を自動化・大量実行し、情報収集、予約枠の占有、在庫の買い占め、ポイントやクーポンの不正利用などにつなげる。

このとき、HTTP リクエストは形式上正しく、ログイン済みのセッションも付いているかもしれません。SQL インジェクションのような典型的な攻撃文字列も含まれないことがあります。WAF から見ると、一見通常の利用者が正規の API を呼び出しているように見える可能性があります。

この種の問題は、OWASP の API セキュリティリスクでも明確に扱われています。例えば「Broken Object Level Authorization (オブジェクト単位の認可不備)」では、API に渡す ID を変更することで、他の利用者のデータにアクセスできてしまう問題が説明されています。また「Unrestricted Access to Sensitive Business Flows (重要な業務フローへの過度なアクセス)」では、商品購入や予約などの機能を自動化して悪用するリスクが挙げられています。[3]

自動化の広がりを示す一つの材料として、Thales の「2026 Bad Bot Report」は、同社が 2025 年に観測したデータにおいて、AI を利用したボット攻撃が前年比 12.5 倍に増え、ボット攻撃の 21 % がビジネスロジックを標的としていたと報告しています。ただし、これは同社の観測範囲に基づく数値であり、インターネット全体の攻撃比率を示す統計ではありません。それでも、単純な不正リクエストの遮断だけでなく、正規の機能がどのように自動化・悪用されるかを考える必要性を示しています。[4]

ここで区別すべきなのが、 認証 (Authentication) と認可 (Authorization) です。

• 認証 : 誰が アクセスしているのかを確認すること。
• 認可: その利用者が、 どの情報を閲覧し、どの操作を実行してよいのか を確認すること。

ログインに成功したことは、あらゆるデータや機能へのアクセスが許可されたことを意味しません。利用者本人の注文情報だけを見られるのか、管理者機能を呼び出せるのか、予約や決済をどの頻度・条件で実行できるのか。こうした判断は、アプリケーション側で業務ルールに基づいて行う必要があります。

また、盗まれたセッション ID や認証トークンが悪用される場合もあります。WAF が通信を検査できても、その通信を送っているのが本来の利用者本人なのか、正規のセッションを奪った第三者なのかを、HTTP リクエストだけで常に判別できるわけではありません。セッション管理、重要操作時の再認証、異常な利用パターンの検知などを組み合わせる必要があります。

サーバーへの侵入だけで被害が終わるとは限らない

アプリケーションやミドルウェアの脆弱性が悪用され、攻撃者がサーバー上でコードを実行できる状態 (RCE: Remote Code Execution) に至れば、影響はサーバー単体にとどまらない可能性があります。

• Web サイトのコンテンツや配信ファイルが改ざんされる。
• 訪問者が偽サイトへ誘導されたり、悪意あるスクリプトを読み込まされたりする。
• サーバーに保存された認証情報やデータベース情報が窃取される。
• 内部ネットワークや関連サービスへの侵入の足場にされる。
• 不正な通信やコンテンツ配信に使われ、ドメインやサービスの信用が損なわれる。

これらが必ず発生するという意味ではありません。しかし、Web サイトを提供する組織は、サーバーを守るだけでなく、そのサイトを利用する顧客、訪問者、連携先にどのような影響が及ぶかまで考える必要があります。

3. WAF 導入後にも、運用上の負担と盲点が残る

WAF は導入すれば自動的に最適な状態が続く製品ではありません。ルールセットの更新、検知ログの確認、誤検知の調整、サービス変更に伴うポリシー見直しが必要です。

特に注意したいのは、WAF の保護対象となる通信経路です。WAF を経由せずにオリジンサーバーへ直接アクセスできる経路が残っていれば、その経路からの通信には WAF の検査が適用されません。また、HTTPS 通信をどこで復号・検査しているのか、API や WebSocket など対象の通信方式が保護範囲に含まれるかも確認が必要です。

さらに、WAF の誤検知を避けるために例外ルールを追加し続けた結果、本来防ぎたい通信まで許可してしまうこともあります。WAF の導入費用や契約の有無だけでなく、実際にどの通信を検査し、何を遮断し、何を見逃す可能性があるのかを把握しなければなりません。

4. WAF を含む多層防御をどう組み立てるか

WAF を有効に活用するには、WAF の前後にある仕組みを含めて防御を設計する必要があります。重要なのは、高価な製品を一度に大量導入することではありません。自社の資産・脅威・事業影響を把握し、優先順位を付けて継続的に改善することです。

                         外部の利用者・攻撃者
                                  |
                                  v
                    +---------------------------+
                    | CDN / DDoS 対策 / 入口制御 |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | WAF                       |
                    | Web 通信の検査・遮断       |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | Web アプリケーション / API |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | 認証・認可・業務ルール     |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | DB / 内部サービス         |
                    +---------------------------+

  ---------------------------------------------------------------
  システム全体を支える横断的な管理

  [資産・依存関係の棚卸し]  [パッチ・設定管理]  [最小権限]
  [ログ監視・異常検知]      [インシデント対応]  [バックアップ]
  [復旧訓練・ネットワーク分離]

  注意: 公開サーバーへの直接アクセス経路が残っていると、
        WAF を通らない通信が発生する可能性がある。

WAF は、この構造の中で HTTP 層を担当する一つの防御点です。守る対象や機能に応じて、CDN、DDoS 対策、API ゲートウェイ、ボット管理などを組み合わせることは有効ですが、それぞれの役割と責任範囲を混同しないことが大切です。

5. 経営者・管理者層が確認すべきこと

WAF の性能やルール設定を現場に任せきりにせず、経営・管理側は次の事項を確認してください。

      +-----------------------+
      | 保護対象・資産の把握  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 脅威と事業影響の分析  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 対策の優先順位を決定  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 予算・責任者・期限設定|
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 実装・監視・検証      |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 結果を評価して見直す  |
      +-----------------------+
                  |
                  +-----------> 次の評価サイクルへ

特に、次の三点は経営判断として明確にしておくべきです。

第一に、セキュリティ対策に優先順位を付けること。 すべてのシステムに同じ投資を行うのではなく、取り扱う情報、利用者数、公開範囲、停止時の事業影響、侵害時の損害を踏まえてリスクを評価します。顧客情報や決済情報を扱うシステム、事業継続に不可欠なシステムは、より高い保護水準が必要です。

第二に、WAF の導入を完了条件にしないこと。 WAF の契約や設置が終わっても、ルールが適切に適用され、ログが確認され、例外が管理され、対象システムの脆弱性が修正されていなければ、十分な対策とは言えません。導入後の運用責任者と評価指標を決めてください。

第三に、長期的な改善を予算化すること。 OS、Webサーバー、ミドルウェア、CMS、プラグイン、アプリケーションの更新には継続的な費用と人員が必要です。基盤の入れ替えがすぐには難しい場合でも、暫定策、恒久修正、移行・廃止の期限を分けて計画する必要があります。

結び: WAF を導入したことではなく、守り続けられることが重要

WAF は不要な製品ではありません。適切に導入・設定・運用すれば、Webアプリケーションに対する多くの攻撃を検知・遮断し、脆弱性修正までの時間を稼ぐ有効な防御策になります。

しかし、WAF は脆弱な基盤を健全な状態に変えるものではありません。正規のセッションを使ったAPI悪用や、アプリケーションの認可不備、内部ネットワークへの侵入、侵害後の不正活動まで、単独で完全に防ぐものでもありません。WAF を「導入したから安心」という免罪符にしてしまえば、根本的な弱点を見逃し、必要な対策を先送りする危険があります。

経営者・管理者層が取り組むべきことは、セキュリティ製品の導入数を増やすことだけではありません。自社のシステムとデータを把握し、どの脅威がどの事業リスクにつながるかを分析し、基盤・アプリケーション・利用者・運用の各層に対策を配置することです。そして、その対策を定期的に見直し、脆弱性の修正、監視、訓練、復旧を継続することです。

WAF は「完全な鎧」ではありません。多層防御の一部として正しく使い、残る弱点を把握し、埋め続けること。それが、顧客と事業を守るためのセキュリティマネジメントです。

参考資料・出典

1. AWS, “AWS WAF Documentation” — WAF が保護対象へ転送される Web リクエストを検査し、条件に応じてカウント、遮断、許可、チャレンジを行う機能の説明。製品ごとに機能・対応範囲は異なる。 https://docs.aws.amazon.com/waf/
2. OWASP, “Virtual Patching Cheat Sheet” — 仮想パッチの定義、既知の攻撃経路を一時的に遮断する利点、基礎となる脆弱性は残ること、回避可能性の検証と恒久修正の必要性。 https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
3. OWASP API Security Top 10 – 2023 — API1「Broken Object Level Authorization」、API5「Broken Function Level Authorization」、API6「Unrestricted Access to Sensitive Business Flows」など、APIの認可不備や業務フロー悪用に関するリスク。 https://api-security.owasp.org/editions/2023/en/0x11-t10/
4. Thales, “2026 Bad Bot Report” — 2025年の同社観測データに基づくボット活動の分析。AIを利用したボット攻撃やビジネスロジックを狙う攻撃への関心を示す業界レポート。数値は同社の観測範囲に基づくもので、インターネット全体を代表する統計ではない。 https://cpl.thalesgroup.com/resources/application-security/2026-bad-bot-report
5. OWASP API Security Project, “API6:2023 Unrestricted Access to Sensitive Business Flows” — 商品購入、投稿、予約などの重要な業務フローが自動化・過剰利用されるリスクと対策の考え方。 https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/

本記事は、WAF を否定するものではありません。WAF の有効性を認めたうえで、その防御範囲と限界を明確にし、他の対策と組み合わせる必要性を論じています。製品の具体的な機能・対応プロトコル・検知範囲は、利用するWAF の仕様と設定を確認してください。