WAFは本当に必要か。「入れれば安全」でも「なくても平気」でもない、自社サイトでの判断軸

「WAFを入れましょう」と言われて、判断に困ったことはないでしょうか。

年間で十数万円から。決して大きな金額ではありませんが、何がどう良くなるのかが分からないまま払い続けるのは気持ちの良いものではありません。調べてみても、出てくるのは製品の比較記事ばかりです。

理由ははっきりしています。WAFについて書いている記事の多くが、WAFを売っている会社のものだからです。実際に「WAF 必要性」で検索して上位に出てくる記事を調べたところ、14件中13件がWAFベンダーか比較サイトでした。そして当然ながら、売る側は「要らないかもしれません」とは書けません。

先に結論を書きます。WAFが要るかどうかは、サイトの規模ではなく「中身」で決まります。そしてWAFは時間を稼ぐ手段であって、問題を解決する手段ではありません。

私たちは受託でシステムを作る会社であって、WAFをはじめとするセキュリティ製品を販売してはいません。入れても売上にならない立場なので、要否をそのまま書けます。そのうえで、納めたシステムが攻撃を受ければ、調査も改修も私たちの仕事です。

結論。WAFが要るかは「サイトの中身」で決まる

「うちは小さいサイトだから狙われない」という判断は、残念ながら成り立ちません。攻撃の多くは特定の企業を狙ったものではなく、脆弱性のあるサイトを機械的に探して回っているからです。規模は判断材料になりません。

見るべきなのは、サイトに何があるかです。

タップで拡大

3つの段階で考える

「要る／要らない」で線を引こうとすると、実はうまくいきません。ほとんどのサイトが「要る」側に入ってしまうからです。理由は次の節で説明します。

そこで、段階で考えます。

判断するのは「入力欄の有無」ではありません

段階1と2の境目が、いちばん誤解されるところです。

問い合わせフォームがあるかどうかで判断してしまいがちですが、それでは足りません。見るべきなのは、サーバーが利用者から届いた値を見て、応答を組み立てているかです。

たとえば次のものは、すべて「値を受け取っている」に入ります。

理由は単純で、攻撃者はブラウザを使わないからです。画面のボタンを押す代わりに、その宛先へ直接、任意の値を投げます。画面に入力欄が無いことは、そこに何も送れないことを意味しません。

逆に、画面の中で完結するボタンは対象外です。メニューの開閉、タブの切り替え、カルーセルの送り、ページ先頭へ戻る、tel: や mailto:のリンク。これらは押しても通信が発生しません。

段階1のサイトは、実際にはあまり多くありません

段階1に当てはまるのは、事前に書き出したHTMLをそのまま置いてあり、問い合わせは電話かメールだけというサイトです。実在はしますが、多くはありません。

Webで問い合わせを受ければ、その時点で値を受け取る処理が生まれます。ここが「ほとんどのサイトが該当してしまう」と書いた理由です。

なお、WordPressのようなCMSを使っているなら、それは段階1ではありません。管理画面というログイン機能があり、プラグインという外部のコードが動いています。段階3として扱ってください。

段階1でも残るリスク

「静的サイトだから何もしなくていい」ではありません。ここは正直に書いておきます。

データが無くても、サイトを書き換えられるリスクは残ります。書き換えられた結果、訪問者にマルウェアを配る踏み台にされれば、自社が加害者の側に回ります。この場合、被害を受けるのは自社ではなくお客様です。

また、後で見るIPAの統計では、DNS情報の設定不備が届出の10%を占めています。これはサイトの中身とは別のところで起きる問題です。

段階1のサイトで、最低限やること

段階1では、守る対象が変わります。サイトの中身ではなく、サイトを差し替えられる立場にあるものです。

1. ドメイン・DNS・ホスティングの管理アカウントに二要素認証をかける

ここを取られると、サイトが静的かどうかに関係なく、まるごと差し替えられます。ドメインの登録業者、DNS、サーバーやストレージの管理画面が対象です。中身を固くしても、ここが弱ければ意味がありません。

2. 使っていないサブドメインと古いページを消す

キャンペーン用に作って放置したサブドメイン、外部サービスを解約したのに残っているDNSの設定。向き先が消えたサブドメインは、第三者に取られて別のサイトを載せられることがあります。自社のドメインで、見知らぬページが公開される形になります。

3. 誰がサイトを差し替えられるかを、把握しておく

退職者の権限、制作会社に渡したままの認証情報。攻撃されるより先に、把握できていないことのほうが問題です。

WAFがないと何が起きるか

ここからは公的な統計で見ていきます。IPA（情報処理推進機構）が四半期ごとに公表している「ソフトウェア等の脆弱性関連情報に関する届出状況」の2026年第1四半期版を使います。

届出の実態

ウェブサイトの脆弱性について、2004年7月の受付開始から積み上がった届出は、不受理を除いて累計13,234件。その種類別の内訳のうち、IPAが本文で挙げている上位3種類がこちらです。

上位2つで全体の3分の2を占めます。そしてこの2つは、WAFが最も得意とする攻撃です。

影響の側から見ると、累計で「本物サイト上への偽情報の表示」「データの改ざん、消去」「ドメイン情報の挿入」が全体の約8割を占めています。個人情報の漏洩は3%、サーバ内ファイルの漏洩は9%です。

直っていないサイトが1,057件ある

この統計でいちばん重いのは、種類別の割合ではありません。修正されていない届出の数です。

IPAは脆弱性の届出を受けると、そのサイトの運営者に連絡します。そして修正を促し、1〜2ヶ月ごとに繰り返し連絡を試みます。それでも報告が来ないものが、統計に残ります。

取扱い中の届出の半分以上が、90日経っても直っていません。この割合は2024年の47%から一貫して増え続けています。

さらに、この1,057件のうち約16%がSQLインジェクションです。IPAはこれを「深刻度の高い脆弱性」「ウェブサイトの情報が窃取されてしまうなどの危険性が高いもの」と明記しています。

なお、修正が完了したものについては、90日以内に完了した割合は累計で70%です。直る場合は比較的早く直り、直らない場合はずっと直らない、という二極化が見て取れます。

この数字が意味すること

ここから読み取れるのは、「攻撃が怖い」という話ではありません。

脆弱性は、指摘されても直らないことがあるという現実です。

理由はさまざまでしょう。作った会社と連絡が取れない。改修の予算がない。担当者が退職して誰も中身を知らない。そもそも通知が届いていない。どれも珍しい話ではありません。

そしてこの状況こそが、WAFの存在理由です。WAFは脆弱性を直しません。直っていない状態のまま、攻撃が届くのを遅らせるための仕組みです。

ただし、ここで注意が必要です。「WAFがあればこれらの事故は防げた」とは言えません。統計には、そのサイトがWAFを導入していたかどうかの情報がありません。次の節で、WAFに何ができて何ができないかを整理します。

WAFが防げるもの、防げないもの

タップで拡大

防げるもの

WAFはWebアプリケーションへの通信を見て、攻撃と分かっているパターンを遮断します。届出の上位を占めるクロスサイト・スクリプティングとSQLインジェクションは、典型的なパターンがある程度知られているため、WAFが得意とする領域です。

言い換えると、WAFが守ってくれるのは「よくある攻撃」です。統計上、これが大半を占めることも事実です。

防げないもの

一方で、WAFの外側にあるものもはっきりしています。

とくに2つ目は見落とされがちです。「本来Aさんしか見られない画面が、URLを書き換えるとBさんからも見えてしまう」といった不備は、WAFから見れば普通のアクセスです。

「バイパスされる」という現実

もう一点、知っておいたほうがよいことがあります。WAFは回避される場合があります。

NTT東日本が公開している検証記事では、AWS WAFに対して実際に検知を回避する手法（リクエストのサイズ制限を利用する、JSONの文字を別の表記に置き換える等）が試され、成立することが示されています。製品の欠陥というより、「パターンで見分ける」という仕組みに由来する限界です。

これはWAFが無意味だという話ではありません。「入れたから安全」という前提を持ってはいけない、という話です。

入れられないときの最低限。優先順位つき

ここからは段階2以上を想定しています。予算が付かない、契約の都合で入れられない、判断がまだ、という状況もあります。何もしないよりましな手はあります。費用が低く効果が高い順に並べます。

まずやる（費用ゼロ）

1. ソフトウェアを最新にする

CMS・プラグイン・テーマ・ライブラリを更新します。攻撃の多くは既に修正済みの脆弱性を狙います。更新しているだけで、対象から外れる攻撃が相当あります。

2. 使っていない機能を止める

使っていないプラグイン、テスト用に作ったページ、退職者のアカウント。動いていないものは攻撃されないのではなく、誰も見ていないぶん危険です。消してください。

3. 管理画面を守る

管理画面のURLを既定のままにしない。パスワードを使い回さない。可能なら二要素認証を有効にする。IP制限がかけられるなら、それがいちばん確実です。

4. バックアップを取り、戻せることを確かめる

これは攻撃を防ぐ対策ではありません。起きてしまった後の被害を小さくする対策です。取っているだけでは足りず、実際に戻せるかを一度試してください。戻せないバックアップは無いのと同じです。

次にやる（低コスト）

5. 何が動いているかを書き出す

サイトを構成しているもの（サーバー、CMS、プラグイン、外部サービス）と、その連絡先を一覧にします。地味ですが、何かあったときに最初に困るのがこれです。

6. 脆弱性診断を受ける

WAFが「攻撃を遅らせる」ものであるのに対し、診断は問題そのものを見つけるためのものです。改修のタイミングで受けるのが効率的です。

それでも残るリスクを、正直に見積もる

ここまでやっても、これで十分とは言えません。

上の対策で減らせるのは「既知の脆弱性を狙った、機械的な攻撃」です。設計の不備や、まだ知られていない脆弱性は残ります。WAFを入れた場合でも残るのは、前の節で見たとおりです。

大事なのは、残っているリスクを把握したうえで選ぶことだと考えます。「対策をしたから大丈夫」と思い込むことが、いちばん危ない状態です。

入れたあとに残る宿題

最後に、WAFを導入した場合の話を書いておきます。

WAFを入れても、脆弱性は残ったままです。

WAFは、攻撃が届く前に遮断する仕組みです。裏返せば、遮断され続けている間、問題のあるコードはそのまま動いています。回避手法が見つかれば、そこから先は無防備です。

ですから、WAFは次のように位置づけるのが正確だと考えます。

WAFは、修正するまでの時間を買うもの。

時間を買ったなら、その間に直す。これがセットです。時間だけ買って直さなければ、支払いを先送りしているのと変わりません。

先ほどの統計に戻ります。90日以上直っていない届出が1,057件、しかもその割合は増え続けています。この数字は、時間を買ったまま使わなかった結果を含んでいるはずです。

「直す」とは、何をすることか

「時間を買ったら直す」と書きました。では、その「直す」とは何をすることなのか。ここを書かずに終わると、ただの言い回しになってしまいます。

IPAは、ウェブアプリケーションの脆弱性対策を2つに分けています。

根本的解決：「脆弱性を作り込まない実装」を実現する手法

保険的対策：「攻撃による影響を軽減する対策」。根本的解決とは違って、脆弱性の原因そのものを無くすものではありません

WAFは後者です。そしてIPAはこう続けます。

保険的対策は脆弱性の原因そのものを無くす対策ではありませんので、保険的対策のみに頼る設計は推奨されません。

（中略）費用や時間、その他の事情によりすぐに実施できない場合には、保険的対策は暫定対策として機能します。

「暫定対策」。これがWAFの位置づけです。この記事で「時間を買うもの」と書いてきたことは、公的な資料ではこう表現されています。

では、根本的解決とは何なのか。届出の上位2つについて、IPAの答えは短いものです。

SQLインジェクション

SQL文の組み立ては全てプレースホルダで実装する。

データベースへの命令文を組み立てるとき、利用者が入力した文字をそのままつなげて作る書き方があります。この場合、入力欄に命令文の断片を書き込まれると、文の意味そのものが変わってしまいます。「検索語」のつもりで受け取った場所が、「全件を持ち出せ」という命令に化けます。

プレースホルダは、命令文の雛形に「ここに値が入る」という印だけを置き、実際の値を後から機械的に割り当てる書き方です。何を入れられても「値」としてしか扱われません。

IPAは、このうち「静的プレースホルダ」について原理的にSQLインジェクション脆弱性の可能性がなくなると書いています。

クロスサイト・スクリプティング

ウェブページに出力する全ての要素に対して、エスケープ処理を施す。

エスケープ処理とは、< や > のようにブラウザが命令の記号として解釈してしまう文字を、ただの文字として表示される形に置き換えることです。これをしないと、投稿や検索語として受け取った文字列が、そのままページの命令として動いてしまいます。

現代の開発フレームワークは、これを既定で行います。ですから実務で問題になるのは、書き忘れよりもエスケープを意図的に外している箇所です。外す書き方には決まった名前があるため、コードを検索すれば場所を特定できます。

IPAも、画面を後から書き換える処理（innerHTML等）について「上記と同様の処理が必要」と明記しています。

発注者として確認できること

技術の中身に立ち入らなくても、この3つは聞けます。

1. SQLの組み立ては、すべてプレースホルダになっていますか
2. 出力のエスケープを外している箇所は、どこに何箇所ありますか
3. そこに、外部から来た値が通っていませんか

この3つに即答できるなら、直す作業自体は大きくありません。答えがすぐ出てこない場合は、「どこにあるか調べる」ところからになります。そこも含めて見積もってもらってください。

大事なのは、根本的解決は「製品を買う」ではないという点です。プレースホルダもエスケープも、追加の費用がかかる仕組みではなく、書き方です。だからこそ、WAFで時間を買ったなら、その時間で直せます。

「ちゃんと作れば要らない」のか

ここまで読むと、こう思うかもしれません。「最初から正しく実装すれば、WAFは要らないのでは」。

半分は当たっています。自社で書いたコードのXSSとSQLインジェクションは、正しく実装すれば原理的に防げます。IPAがWAFの効果として挙げているのは「脆弱性を悪用した攻撃」への防御と検出だけで、脆弱性が無ければ守るものがありません。

ただし、成り立たない場合が2つあります。

1. そもそも直せない脆弱性がある

IPAは、WAFの使用が有効な状況としてこう書いています。

商用製品やオープンソースソフトウェアを使用してウェブサイトを構築した場合、該当ソフトウェアの改修に直接関与できず、脆弱性を修正できないことがあります。（中略）開発元が脆弱性を修正したバージョン、または修正パッチを提供しない限り、脆弱性を修正できません。

CMSのプラグイン、使っているライブラリ。自社のコードが完璧でも、この状況は起きます。そして直す手段がありません。修正が出るまでの間、WAFが唯一の手になります。

IPAはもう1つ、開発した会社に改修を頼めない状況（事業から撤退している、他社に頼むと予算に収まらない）も挙げています。

2. 「不備が無い」ことは証明できない

脆弱性診断が言えるのは「見つかった範囲では問題なかった」までです。「無い」ことは示せません。検証できない前提の上に立った判断は、使えません。

ですから、正確にはこうなります。

WAFが要るのは「脆弱性が存在するから」です。ただし、その脆弱性が自社の落ち度とは限らず、無いことも証明できません。

「ちゃんと作らせれば済む」で終わらせられないのは、この2点があるためです。

まとめ

• 要否はサイトの規模ではなく中身で決まります。判断するのは入力欄の有無ではなく、サーバーが値を受け取って処理しているかです。この基準では、ほとんどのサイトが該当します。問うべきは「要るか」ではなく「どこまでやるか」です
• WAFが防ぐのは「よくある攻撃」です。統計上これが大半を占めるため効果はありますが、未知の攻撃・設計の不備・回避手法には無力です
• 入れられないなら、更新・不要物の削除・管理画面の保護・バックアップから始めてください。費用ゼロで効果があります
• どの対策も「これで十分」にはなりません。残るリスクを把握したうえで選んでください
• WAFは時間を買うものです。買った時間で直してください

自社のサイトに何が必要か、判断がつかない場合はご相談ください。作った側ではない立場からでも、構成を確認して優先順位をつけるところまではお手伝いできます。「まず何から手を付けるか」がはっきりするだけでも、動きやすくなるはずです。