公開2026.07.08更新2026.10.02 セキュリティ

WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説

WAF（Webアプリケーションファイアウォール）とは、Webサイトやアプリケーションへの通信を中身まで検査し、SQLインジェクションやクロスサイトスクリプティングといったWebアプリを狙う攻撃を遮断する防御の仕組みです。同じ「ファイアウォール」という語が付いても、通信の宛先とポートだけを見る従来のファイアウォールとは守る階層が違います。この記事で扱うのは、WAFが守るWebアプリ層とOWASP Top 10:2025、シグネチャによる検知の仕組み、ファイアウォールやIPS・IDSとの守備範囲の差、アプライアンス型・ソフトウェア型・クラウド型（AWS WAF・Azure）の費用構造です。OSSのWAFとAWS WAFを手元で動かして遮断を確かめる設定例、WAFで防げる攻撃と防げない領域、自社にWAFが費用対効果で見合うかの判断基準まで、導入と運用の解像度で整理します。

まとめ｜WAFはWebアプリを狙う攻撃を検知・遮断する専用の壁

WAFは、公開されたWebアプリケーションの前段に置き、HTTP／HTTPS通信のリクエストとレスポンスの中身を検査する防御装置です。従来のファイアウォールがIPアドレスやポート番号で通信の可否だけを判定するのに対し、WAFはリクエストのパラメータやヘッダーの中身まで読み、Webアプリの脆弱性を突く攻撃パターンを見つけて止めます。守る対象がネットワークではなくアプリケーションそのものである点が、他の防御機器との決定的な違いです。

ただし、WAF1台で守りが完結するわけではありません。WAFが得意とするのはWebアプリ層への既知パターンの攻撃で、未知のゼロデイの一部や、正規の認証情報を悪用したなりすまし、回線を溢れさせる大規模なDDoSまでは単体で防ぎ切れません。アプリの内部から実行時に攻撃を止める手段としては、RASPの仕組みとWAFとの違いが選択肢になります。導入形態も、拠点に機器を置くアプライアンス型からAWS WAF・Azureのようなクラウド型まで幅があり、費用とチューニングの手間が変わります。AWS WAFなら公開単価で月十数ドルから始められますが、費用より重いのは誤検知を潰す運用の手間です。まず検知だけのモードで動かし、ログを見てから遮断に切り替える。この順番を守れるかが成否を分けます。

WAF（Webアプリケーションファイアウォール）とは何か｜守る層と仕組み

WAFはWeb Application Firewallの略で、Webアプリケーションに特化したファイアウォールです。Webサーバーの手前にリバースプロキシとして配置し、利用者からのHTTPリクエストを一度受け止めて検査してからアプリへ渡します。攻撃と判定した通信はここで遮断し、正常な通信だけを通す。この「アプリの前で通信の中身を読む」構えが、ネットワークの入口で可否を切り分ける従来型の防御とは異なります。国内の公的な解説としては、IPAが導入判断・導入・運用の3工程で要点をまとめたWeb Application Firewall（WAF）読本があり、2011年公開の改訂第2版ながら、検知方式と運用の考え方は現在の製品にもそのまま当てはまります。

WAFが守るWebアプリケーション層とOWASP Top10の主要な攻撃

WAFが守るのは、通信の階層でいうアプリケーション層（L7）です。ここはHTTPのパラメータやCookie、フォームの入力値がやり取りされる層で、プログラムの作りの甘さを突く攻撃が集中します。具体的な脅威の目録として広く参照されるのが、非営利団体OWASPが公開するOWASP Top 10で、2026年10月時点の現行は2025年版です。2025年版ではXSSを含むA05:2025 Injection、A01:2025 Broken Access Control（アクセス制御の不備）、A02:2025 Security Misconfiguration などが並びます。2021年版からの組み替えはOWASP Top 10 2025年版の10項目と変更点で整理しています。

多くのWAF製品は、このうちインジェクション系のように「リクエストの文字列に攻撃の形が現れる」項目に対応する検知ルールを標準で備えます。ネットワーク機器では中身を読まないため素通りしてしまう攻撃を、アプリの手前で止める役割をWAFが担います。逆に、A01のアクセス制御の不備は正規の形のリクエストで起こるため、WAFが最も苦手とする項目です。URLのIDを書き換えるだけで他人のデータに触れられるBOLAのようなAPIの認可の欠陥もここに入ります。API層の防御を認証・認可の設計まで含めて捉えたい場合は、APIセキュリティとはを参照してください。

シグネチャ照合とブラックリスト・ホワイトリスト方式の検知の仕組み

WAFの検知方式は、大きく2つの考え方に分かれます。1つは、既知の攻撃パターン（シグネチャ）と通信を照合し、一致したものを攻撃として弾くネガティブセキュリティモデルです。ブラックリスト型とも呼ばれ、SQLインジェクションで多用される文字列パターンなどをあらかじめ登録しておきます。もう1つは、正常な通信の形をあらかじめ定義し、そこから外れた通信を拒否するポジティブセキュリティモデル（ホワイトリスト型）です。前者は導入が速い反面、未知のパターンには弱く、後者は精度が高い代わりに正常通信の定義を作り込む手間がかかります。実運用の製品は、シグネチャを土台にしつつ、通信量やアクセス頻度の異常を見る仕組みを組み合わせるものが主流です。

代表的なOSSのルール集であるOWASP CRS（Core Rule Set）は、1つのルールに一致しただけで即遮断はしません。一致したルールごとに点数を足す「異常スコア方式」を採り、合計が閾値（既定は5点）に達したリクエストを遮断します。検知の厳しさは「パラノイアレベル」1〜4で切り替え、既定の1は誤検知が少ない代わりに検知は控えめです。CRSは2026年8月公開の4.29系が最新で、長期サポート版として4.25系も提供されています。

WAFとファイアウォール・IPS／IDSの違いと守備範囲の住み分け

WAFで最も混同されるのが、ファイアウォールやIPS・IDSとの違いです。名前や役割が近く見えますが、この3種は競合する製品ではなく、通信のどの層を、どの粒度で守るかが分かれています。多くの現場では対立させず、層を分担させて併用します。

ファイアウォールとの違い｜ネットワーク層とアプリ層の防御範囲

ファイアウォールは、通信の送信元・宛先のIPアドレスとポート番号を見て、通す・通さないを判定する装置です。守る層はネットワーク層（L3／L4）で、通信の中身までは読みません。そのため、許可したポート（Webなら443番など）を通る正規の見た目のHTTPリクエストに攻撃コードが仕込まれていても、ファイアウォールは中身を検査しないので通してしまいます。WAFはその通り抜けた先、アプリの手前で中身を読む役割を担い、両者は上下の関係ではなく、守る層の違いで補い合う間柄です。ファイアウォール単体の仕組みや種類、選び方はファイアウォールとは？仕組み・種類とWAF・UTMとの違い、企業の選び方で概念から整理しています。通信の可否だけならファイアウォール、Webアプリの脆弱性を突く攻撃まで止めたいならWAFを重ねる、という切り分けになります。

IPS／IDSとの違い｜通信全般の監視とWebアプリ特化の検査

IPS（不正侵入防御）・IDS（不正侵入検知）は、ネットワークを流れる通信全般を監視し、攻撃の兆候を検知（IDS）・遮断（IPS）する仕組みです。守備範囲が広く、OSやミドルウェアの脆弱性を突く攻撃、ポートスキャン、マルウェアの通信など、Webに限らない脅威を広く見ます。対してWAFは、対象をHTTP／HTTPSのWebアプリ通信に絞り、その分だけSQLインジェクションやXSSといったアプリ固有の攻撃を深く検査します。「広く浅く」がIPS／IDS、「Webアプリに狭く深く」がWAF、という粒度の違いです。両者の使い分けはIDS・IPSとは？違い・仕組み・種類とファイアウォール／WAFとの使い分けで詳しく扱っています。Webサービスを公開する企業では、IPS／IDSで通信全般を、WAFでアプリ層を、と役割を分けて併用する構成が定番です。

ファイアウォール・IPS／IDS・WAFの守備範囲を一覧で比較

3種の防御は守る層と検査の深さが異なり、下の表のように役割を分担させると位置づけが掴めます。複数機能を1台へ束ねたUTMは、この土台に立つ統合パッケージにあたります。

製品	主に守る層	見る対象	典型的な用途
ファイアウォール	ネットワーク層	IP・ポート	通信の可否判定
IPS／IDS	ネットワーク全般	通信の兆候	侵入の検知・遮断
WAF	アプリ層(L7)	HTTPの中身	Webアプリ防御

ファイアウォールで入口を絞り、IPS／IDSで通信全般を見張り、WAFでWebアプリを守る。3層を重ねると、単体では抜ける攻撃を段階で受け止められます。これらを1台に集約した統合型についてはUTMとは？統合脅威管理の機能とファイアウォールとの違いで解説しています。

WAFの3つの導入形態｜アプライアンス型・クラウド型の選び分け

同じWAFでも、どこに配置し誰が運用するかで3つの形態に分かれます。自社のシステムがオンプレミスにあるかクラウドにあるかで、向く形態と費用の構造が変わります。

アプライアンス型・ソフトウェア型・クラウド型という3形態の違い

アプライアンス型は、専用のハードウェア機器を自社のネットワークに設置する形態です。処理性能が高く大規模サイトに向く一方、機器の購入・保守と運用要員が要ります。ソフトウェア型は、既存のサーバーにWAFソフトを導入する形態で、ModSecurityとOWASP CRSの組み合わせが代表例です。機器を持たずに柔軟に構成できる反面、サーバー側のリソースを消費し、設定には専門知識が要る点に注意が必要です。クラウド型（クラウドWAF／WaaS）は、通信をクラウド上のWAFサービスに経由させる形態で、自社に機器もソフトも持たず、DNSの向き先を変えるだけで導入できます。初期投資を抑えて短期間で始められるため、現在は中小規模からの導入で主流になっています。

形態	設置場所	初期費用	向く規模
アプライアンス型	自社に機器設置	高い	大規模・高負荷
ソフトウェア型	既存サーバー	中程度	中規模・要専門
クラウド型	クラウド経由	低い(月額)	中小〜大規模

守る対象がクラウド上のWebサービスなら、経路をそのままクラウドで検査できるクラウド型が素直な選択になります。

クラウドWAF（AWS WAF・Azure）のマネージドルールと料金体系

クラウド型の代表がAWS WAFやAzureのWAFです。これらは、ベンダーが用意した検知ルールのまとまり（マネージドルール）を有効化するだけで、OWASP Top 10相当の攻撃への対応を始められます。AWS WAFでは、共通の攻撃に対応するAWSマネージドルールのベースライン群を土台に、必要に応じて自社ルールを追加する構成が基本です。中心になるAWSManagedRulesCommonRuleSetは700WCU（ルールの処理コストを表す単位）、Log4jなどの既知の悪性入力を止めるAWSManagedRulesKnownBadInputsRuleSetは200WCUを消費します。ルールの追加と更新そのものを外部サービスに任せる方法もあり、その仕組みと費用はWafCharmの導入手順・WCU消費・料金の実額で扱っています。

料金は機器の買い切りではなく、月額と従量の組み合わせです。AWS WAFの料金ページの2026年10月時点の公開単価は、Web ACL 1つが月5ドル、ルール1本が月1ドル、検査したリクエスト100万件ごとに0.60ドルでした。Web ACL 1つにマネージドルールグループ1つと自社ルール2本を載せ、月1,000万リクエストを検査すると、5ドル＋3ドル＋6ドルで月14ドル前後の計算になります。既定の1,500WCUを超える構成や、Bot Controlなどの有償ルール群を足すと単価が上がるため、実際のリクエスト数を当てはめた試算が前提です。AzureのWAFはApplication Gatewayに統合して提供され、その概要はAzure Application Gatewayとは何か？その概要と重要性を解説で扱っています。クラウド全体の守り方の枠組みはクラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方で整理しました。

WAFの動きを手元で確かめる手順｜OSSのWAFとAWS WAFの設定例

WAFが何を止めて何を通すかは、資料を読むより実際にリクエストを投げたほうが早く掴めます。ここでは費用をかけずに試せるOSSのWAFと、本番で使うことの多いAWS WAFの2通りで、検知の流れを確かめる手順を示します。

OWASP CRSのDockerイメージでSQLインジェクションの遮断を試す手順

CRS公式のmodsecurity-crs-dockerは、ModSecurityとCRSを組み込んだリバースプロキシのイメージです。環境変数BACKENDに守りたいアプリを指定すると、8080番ポートで受けたリクエストを検査してから転送します。下の例は、nginxの初期ページを守る対象に見立てた最小構成です。

# 検証用ネットワークと、守る対象のアプリ（nginx初期ページ）を起動
docker network create waf-lab
docker run -d --rm --name app --network waf-lab nginx:alpine

# CRS入りのWAFを前段に置く（パラノイアレベル1・異常スコア閾値5が既定）
docker run -d --rm --name waf --network waf-lab -p 8080:8080 \
  -e BACKEND=http://app:80 \
  -e BLOCKING_PARANOIA=1 \
  owasp/modsecurity-crs:nginx

# 正常なリクエスト（200が返る想定）
curl -s -o /dev/null -w "%{http_code}\n" "http://localhost:8080/?id=1"

# SQLインジェクションの典型パターン（403で遮断される想定）
curl -s -o /dev/null -w "%{http_code}\n" "http://localhost:8080/?id=1%27%20OR%20%271%27%3D%271"

# 遮断の理由（一致したルールIDと異常スコア）を確認
docker logs waf 2>&1 | grep -i "anomaly"

2本目のリクエストは、CRSのSQLインジェクション検知ルールに一致して異常スコアが閾値に届き、403で止まるのが想定どおりの挙動です。ログには一致したルールIDが残るので、誤検知を調べるときもここが出発点になります。攻撃パターンそのものの仕組みはSQLインジェクションの仕組み・攻撃例・対策で、コード側の直し方まで扱っています。WAFの前後で脆弱性スキャナを当てて差を見たい場合は、OWASP ZAPの診断項目と使い方が手軽に比較するための手段です。

AWS WAFをCLIでCountモード構成し誤検知を確認してから遮断へ移す

AWS WAFで同じことをする場合は、マネージドルールを「Count（数えるだけ）」で載せたWeb ACLを先に作ります。aws wafv2 create-web-aclでは、ALBやAPI Gateway向けならscopeにREGIONAL、CloudFront向けならCLOUDFRONTとus-east-1リージョンを指定します。

# rules.json：CommonRuleSetをCount（検知のみ）で載せる
[
  {
    "Name": "AWS-CommonRuleSet",
    "Priority": 0,
    "Statement": {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesCommonRuleSet"
      }
    },
    "OverrideAction": { "Count": {} },
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "AWS-CommonRuleSet"
    }
  }
]

# 東京リージョンのALB向けWeb ACLを作成（一致しない通信は許可）
aws wafv2 create-web-acl \
  --name demo-web-acl \
  --scope REGIONAL \
  --region ap-northeast-1 \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=demo-web-acl \
  --rules file://rules.json

数週間ほどCountで動かし、サンプリングされたリクエストやCloudWatchのメトリクスで「正規の操作が何件引っかかったか」を確かめます。誤検知が出たルールだけを除外ルールに指定し、残りを”OverrideAction”: { “None”: {} } に書き換えて update-web-acl で反映すれば、ルール群本来のBlock動作に切り替わります。最初から遮断で入れると、問い合わせフォームや管理画面の操作が止まってから原因を探すことになるため、事後の調査が必要です。

WAFで防げる攻撃と、WAF単体では守り切れないセキュリティ領域

WAFの導入判断でつまずきやすいのが、「WAFを入れれば安全」という過信です。WAFが止められる攻撃と、WAFの外側に残るリスクを分けて捉えると、必要な追加対策が見えてきます。

SQLインジェクションやXSSなどWAFが遮断できる代表的攻撃

WAFが得意とするのは、Webアプリの入力を悪用する攻撃です。データベースを不正操作するSQLインジェクション、利用者のブラウザで悪意あるスクリプトを実行させるクロスサイトスクリプティング（XSS）、他人の操作を偽装するクロスサイトリクエストフォージェリ（CSRF）などが代表例で、いずれもリクエストの中身のパターンから検知して遮断するという主な役割を担います。ただしCSRFは、リクエストの形自体は正規の操作と区別しにくく、WAFよりもトークン検証やCookieのSameSite属性で止めるのが本筋です。両者の差はXSSとCSRFの違いを実装レベルで比較した記事で詳しく扱っています。加えて、短時間の大量アクセスを制限するレート制御で、パスワード総当たりや軽度の不正アクセスを抑える製品もあります。アプリのコードを直さなくても、前段のWAFで既知の攻撃パターンを止められる点が、脆弱性の修正が間に合わない場面で得られる実利です。

誤検知（フォルスポジティブ）とWAF運用に必要なチューニング

WAFの運用で避けて通れないのが、正常な通信を攻撃と誤って弾く誤検知（フォルスポジティブ）です。検知ルールを強くするほど攻撃は止まりますが、同時に正規の利用者の入力までブロックし、問い合わせフォームや購入操作が通らなくなります。導入直後にいきなり遮断を有効にせず、まず検知だけを行う監視モードで数週間ログを取り、自社サイト固有の正常通信を許可リストに整えてから防御モードへ切り替えるのが定石です。前章のCountモードやCRSのパラノイアレベル1は、この監視期間を作るための設定にあたります。この初期チューニングと、攻撃手口の変化に合わせたルール更新を継続できるかが、WAFを入れて終わりにしない運用の分かれ目になります。逆に言えば、ルールを放置したWAFは誤検知で使われなくなるか、素通しの飾りになりがちです。

検査サイズ上限8KB・16KBを超えたリクエスト本文が素通りする盲点

見落とされやすいのが、WAFが検査するリクエスト本文の長さに上限がある点です。AWS WAFのサイズ超過時の扱いによると、ALBとAppSyncでは本文の検査範囲が先頭8KBで固定され、CloudFrontやAPI Gatewayは既定16KB（設定で最大64KBまで拡張、拡張分は追加料金）です。マネージドルールの多くは、上限を超えた部分を検査しないまま次の処理へ進む設定になっています。大きなJSONを受けるAPIでは、先頭を無害な値で埋めた攻撃が届く余地が残るということです。CommonRuleSetには8KBを超える本文を遮断するSizeRestrictions_BODYがありますが、ファイルアップロードを扱うサイトでは誤検知の原因になりやすく、除外されがちなルールでもあります。除外するなら、アプリ側の入力検証で長い本文を受ける経路を守る、という代わりの手当てとセットで判断してください。

WAFの導入を判断すべき企業と、導入しても費用対効果が薄い企業の線引き

ここからは製品比較ではなく判断の話です。WAFが費用対効果で効く企業と、入れても効果が限定的な企業を、条件を付けて言い切ります。

公開Webアプリや個人情報を扱う企業がWAFを導入すべき条件

WAFが明確に効くのは、次の条件が重なる企業です。会員登録・問い合わせ・決済など、利用者の入力を受け付ける公開Webアプリケーションを運用している。氏名・連絡先・クレジットカードといった個人情報や機密データをそのアプリで扱う。そして、自社開発や外注のWebアプリで、脆弱性が残っている可能性を完全には排除できない。この3点が揃うと、アプリのコード修正が追いつかない期間の「時間稼ぎ」としてもWAFが有効です。とくにECサイトや会員制サービス、フォームから個人情報を集めるコーポレートサイトは、SQLインジェクションやXSSの標的になりやすく、WAFを前段に置く判断が費用に見合います。

カード情報を扱う事業者には、規格上の要請もあります。PCI SSCが公開するPCI DSSのv4系では、要件6.4.2として公開Webアプリの前段にWeb攻撃を自動で検知・防止する技術的な仕組み（WAFが例示されている）を置くことが、2025年3月31日から必須になりました。この要件の対象なら、導入するかどうかではなく、どの形態で運用するかの検討から始まります。クラウド上でこうした公開システムを運用しているなら、WAFを含めた構成設計をインフラ構築（AWS・Google Cloud・Azure）で相談段階から対応しています。

WAFの導入効果が薄い場面と、運用体制がなければ見送るべき条件

一方で、WAFの費用対効果が薄い場面もあります。外部からの入力を受け付けない静的な情報サイトや、社内に閉じたシステムでインターネットに公開していないアプリでは、Webアプリ層への攻撃面がそもそも小さく、WAFの守る対象が乏しくなります。また、WAFは導入するだけでは機能しません。前述の初期チューニングとルールの継続更新を担う人手がなく、設定を運用ベンダーにも委ねられない体制では、誤検知で止めるか素通しにするかの二択になり、投資が回収できません。守るべき公開Webアプリが無い、あるいは運用を続ける体制もベンダー支援も用意できない——この場合はWAFを急がず、まず狙われている攻撃の種類を整理し、大規模なDDoSが主な脅威ならWAFではなくDDoS攻撃とは？仕組み・種類とDoS攻撃との違い、企業が取るべき対策で扱う専用の対策を優先する、といった見極めが要ります。

もう1つの見送り条件は、WAFを脆弱性の修正の代わりにしようとしている場合です。WAFはあくまで時間稼ぎで、アプリの欠陥そのものは残ります。どこに欠陥があるかを先に洗い出したいなら、脆弱性診断の種類・費用相場・進め方から着手し、診断で見つかった項目のうち修正が間に合わないものをWAFで塞ぐ順番が筋です。WAFは「公開Webアプリを守り、運用を続けられる企業」に効く道具だと割り切るのが実務的です。

よくある質問

WAFの導入検討でよく挙がる質問に回答します。

WAFとファイアウォールの違いは何ですか？

守る通信の層が違います。ファイアウォールはIPアドレスやポート番号を見て通信の可否を判定するネットワーク層の装置で、通信の中身までは読みません。WAFはその先のアプリケーション層で、HTTPリクエストの中身を検査し、SQLインジェクションやXSSといったWebアプリを狙う攻撃を遮断します。許可したポートを通る正規の見た目のリクエストに攻撃が仕込まれていてもファイアウォールは通してしまうため、Webサービスを公開する企業は両者を層で分担させて併用します。

WAFで防げる攻撃と防げない攻撃は何ですか？

WAFが防げるのは、Webアプリの入力を悪用する攻撃です。SQLインジェクション、クロスサイトスクリプティング、パス・トラバーサルなど、リクエストの中身のパターンから検知できるものが対象になります。一方、正規の認証情報を使ったなりすまし、アクセス制御の不備、パターン化されていない未知のゼロデイの一部、回線を溢れさせる大規模なDDoSは、WAF単体では防ぎ切れません。端末対策やDDoS専用の防御、認証の強化などと組み合わせる多層防御が前提です。AWS上のシステムであれば、レイヤー3・4を受け持つAWS Shieldとは？StandardとAdvancedの違い・料金と採用判断が組み合わせ先になります。

クラウド型WAFとアプライアンス型はどちらを選ぶべきですか？

守る対象がどこにあるかで決まります。Webサービスがクラウド上にあり、短期間・低い初期費用で始めたいなら、DNSの向き先を変えるだけで導入できるクラウド型が素直です。大規模で通信量が非常に多く、自社データセンターに公開システムを置いている場合は、処理性能の高いアプライアンス型が向きます。運用要員を確保しづらい組織ほど、ルール更新までベンダーが担うクラウド型の負荷の軽さが効いてきます。

AWS WAFの料金はどのくらいかかりますか？

機器を買い切る形ではなく、月額と従量課金の組み合わせです。2026年10月時点の公開単価はWeb ACL 1つが月5ドル、ルール1本（マネージドルールグループ1つを含む）が月1ドル、検査リクエスト100万件ごとに0.60ドルでした。Web ACL 1つ・ルール3本・月1,000万リクエストなら月14ドル前後の計算です。Bot Controlなどの有償ルール群や、既定の1,500WCUを超える構成では追加の料金がかかります。単価は改定されることがあるため、契約前に料金ページと自社の想定リクエスト数で試算し直してください。

WAFを導入すればセキュリティ対策は十分ですか？

十分にはなりません。WAFはWebアプリ層に特化した防御で、ネットワーク全般を見るファイアウォールやIPS／IDS、端末を守るEDR、メール経由の脅威対策までは担いません。実務では、WAFをWebアプリの守りの一層として位置づけ、ネットワーク機器・端末対策・利用者教育・脆弱性の修正を重ねる多層防御が前提になります。利用者のブラウザ上で成立するため検査点を通らないクリックジャッキングのように、レスポンスヘッダー側でしか止められない攻撃もあります。WAF1台で完結させる発想ではなく、公開Webアプリを守る専用の層として組み込むのが適切です。