WAFのブラックリスト方式とホワイトリスト方式について

2026-06-13

WAFとは、Web Application Firewallの略で、WebサイトやWebアプリケーションを狙った攻撃を検知・遮断するためのセキュリティ対策です。

一般的なファイアウォールは、IPアドレスやポート番号などをもとに通信を制御します。

一方、WAFはHTTP/HTTPS通信の中身を確認し、URL、パラメータ、Cookie、ヘッダー、リクエストボディなどを見て、不正なアクセスかどうかを判断します。

WAFで対策できる代表的な攻撃には、以下のようなものがあります。

SQLインジェクション
クロスサイトスクリプティング、XSS
パストラバーサル
OSコマンドインジェクション
不正なファイルアップロード
脆弱性を突いた不正リクエスト
管理画面への攻撃

また、クラウド型WAFやWAAPと呼ばれる製品では、Bot対策、レート制限、DDoS対策、API保護などの機能を備えている場合もあります。

ただし、これらはWAF製品によって対応範囲が異なるため、導入時には機能を確認することが重要です。

WAFのブラックリスト方式とは

ブラックリスト方式とは、既知の攻撃パターンや不正な特徴に一致する通信をブロックする方式です。

「この文字列が含まれていたら危険」
「このリクエスト形式は攻撃の可能性が高い」
「このIPアドレスからのアクセスは拒否する」

というように、危険なものをルールとして登録し、それに該当する通信を遮断します。

なお、ブラックリスト方式は近年、denylist方式、blocklist方式、またはネガティブセキュリティモデルと呼ばれることもあります。

ブラックリスト方式の仕組み

ブラックリスト方式では、攻撃に使われやすい文字列やパターンをWAFが検知します。

たとえば、ログインフォームや検索フォームに以下のような文字列が送信された場合、SQLインジェクションの可能性があると判断されることがあります。

' OR '1'='1

また、以下のような文字列が送信された場合は、クロスサイトスクリプティング、XSSの可能性があると判断されることがあります。

<script>alert('xss')</script>

このように、ブラックリスト方式では、攻撃でよく使われる文字列、構文、挙動、通信パターンなどをもとに、不正なリクエストを検知します。

ブラックリスト方式のメリット

ブラックリスト方式の大きなメリットは、導入しやすいことです。

既知の攻撃パターンに基づいて判断するため、Webアプリケーションの仕様を細かく定義しなくても、一定の防御効果を期待できます。

特に、WordPressなどのCMSや、一般的なコーポレートサイト、ECサイト、問い合わせフォームを持つサイトでは、よくある攻撃を広く防ぐ目的で導入しやすい方式です。

主なメリットは以下の通りです。

メリット	内容
導入しやすい	Webアプリケーションの仕様を細かく定義しなくても使いやすい
運用開始が早い	初期設定だけで一定の攻撃を検知・遮断できる
既知の攻撃に強い	SQLインジェクションやXSSなど典型的な攻撃を検知しやすい
汎用性が高い	さまざまなWebサイトに適用しやすい
運用負荷を抑えやすい	ベンダー提供のルール更新を活用できる場合がある

ブラックリスト方式のデメリット

ブラックリスト方式の弱点は、未知の攻撃や巧妙に変形された攻撃に弱い場合があることです。

ブラックリスト方式は、基本的に「危険だと分かっているもの」を止める仕組みです。

そのため、まだルール化されていない攻撃や、既存の検知ルールをすり抜けるように難読化された攻撃には対応できない可能性があります。

たとえば、攻撃者が文字列をエンコードしたり、分割したり、別の表現に置き換えたりすると、単純なパターンマッチでは検知を回避されることがあります。

また、ブラックリスト方式でも誤検知は発生します。

特に、以下のようなケースでは、正常な入力が攻撃と判断される可能性があります。

プログラミングコードを投稿するフォーム
HTMLやJavaScriptを含む技術記事の投稿画面
JSONやXMLを送信するAPI
記号やURLを多く含む問い合わせ本文
Base64エンコードされたデータを扱うフォーム

そのため、ブラックリスト方式であっても、導入後はログを確認しながらチューニングすることが重要です。

主なデメリットは以下の通りです。

デメリット	内容
未知の攻撃に弱い	登録されていない攻撃パターンは検知できない可能性がある
回避される可能性がある	エンコードや難読化によって検知をすり抜けられる場合がある
ルール更新が必要	新しい攻撃に対応するため、継続的な更新が必要
誤検知が起きる	正常な通信が攻撃と判断される場合がある
完全防御ではない	既知の攻撃対策が中心になるため、過信は禁物

WAFのホワイトリスト方式とは

ホワイトリスト方式とは、正常な通信の条件をあらかじめ定義し、その条件に合う通信だけを許可する方式です。

ブラックリスト方式が「危険なものを拒否する」考え方であるのに対し、ホワイトリスト方式は「許可されたものだけを通す」考え方です。

なお、ホワイトリスト方式は近年、allowlist方式、またはポジティブセキュリティモデルと呼ばれることもあります。

ホワイトリスト方式の仕組み

ホワイトリスト方式では、Webアプリケーションにとって正常なリクエストの条件を定義します。

たとえば、お問い合わせフォームの場合、以下のような条件を設定します。

項目	正常な条件の例
URL	`/contact/submit` のみ許可
HTTPメソッド	POSTのみ許可
名前	50文字以内
メールアドレス	メールアドレス形式のみ許可
電話番号	数字、ハイフン、必要に応じて国番号などを許可
お問い合わせ内容	1,000文字以内
パラメータ	想定された項目のみ許可

この条件に合わないリクエストは、攻撃パターンに一致していなくても遮断される可能性があります。

たとえば、電話番号欄に以下のような文字列が入力された場合、正常な電話番号形式ではないため遮断対象になります。

<script>alert(1)</script>

また、想定していないパラメータが追加されていた場合も、不正な通信として扱われることがあります。

role=admin

このように、ホワイトリスト方式では「攻撃かどうか」ではなく、「正常な通信として許可されているか」を基準に判断します。

ホワイトリスト方式のメリット

ホワイトリスト方式の大きなメリットは、未知の攻撃にも対応しやすいことです。

攻撃パターンを事前に知っている必要がなく、正常な通信条件に合わないものを拒否するため、まだシグネチャ化されていない攻撃や、変形された攻撃にも対応できる可能性があります。

特に、APIや管理画面のように、リクエストの形式が明確に決まっている領域では効果を発揮しやすい方式です。

主なメリットは以下の通りです。

メリット	内容
未知の攻撃に対応しやすい	正常な通信以外を拒否するため、新しい攻撃にも強い場合がある
セキュリティを厳密にできる	URL、メソッド、パラメータ、文字数などを細かく制御できる
攻撃パターンに依存しにくい	攻撃シグネチャを知らなくても防げる可能性がある
想定外の入力を制限できる	不要なパラメータや不自然な値を拒否できる
API保護と相性がよい	JSONスキーマや必須項目などを定義しやすい

ホワイトリスト方式のデメリット

ホワイトリスト方式のデメリットは、設定と運用が難しいことです。

正常な通信条件を正確に定義するには、Webアプリケーションの仕様を細かく把握する必要があります。

たとえば、以下のような情報を整理しなければなりません。

許可するURL
許可するHTTPメソッド
各フォームの入力項目
パラメータ名
値の型
文字数制限
許可する文字種
Cookieやヘッダーの仕様
APIのリクエスト形式

また、Webサイトに新しいフォームを追加したり、APIの仕様を変更したり、キャンペーン用のパラメータを追加したりするたびに、WAF側のルールも見直す必要があります。

ルールが厳しすぎると、正規ユーザーの正常な操作までブロックしてしまう可能性があります。

たとえば、電話番号欄を「数字とハイフンのみ」と厳格に設定した場合、以下のような入力が拒否されることがあります。

+81を含む国際電話番号
半角スペースを含む電話番号
括弧を含む電話番号
内線番号を含む電話番号
全角数字で入力された電話番号

このように、ホワイトリスト方式ではセキュリティを高められる一方で、ユーザー体験やコンバージョンに影響する可能性もあります。

主なデメリットは以下の通りです。

デメリット	内容
設定が難しい	正常な通信パターンを細かく定義する必要がある
運用負荷が高い	サイト更新や機能追加のたびにルール調整が必要
誤遮断が起きやすい	正常なアクセスでも条件に合わなければブロックされる
初期設計に時間がかかる	アプリケーション仕様の把握が必要
柔軟性が低くなる場合がある	自由入力欄や複雑なAPIでは運用が難しい

ブラックリスト方式とホワイトリスト方式の違い

ブラックリスト方式とホワイトリスト方式の違いは、判断基準にあります。

ブラックリスト方式は、危険なものを見つけて拒否する方式です。

ホワイトリスト方式は、許可されたものだけを通す方式です。

両者の違いを整理すると、以下のようになります。

項目	ブラックリスト方式	ホワイトリスト方式
別名	denylist、blocklist、ネガティブセキュリティモデル	allowlist、ポジティブセキュリティモデル
基本思想	危険な通信を拒否する	正常な通信だけ許可する
判断基準	既知の攻撃パターンや不正な特徴	正常なURL、メソッド、パラメータ、値の形式
未知の攻撃への強さ	弱い場合がある	適切に設定すれば強い
導入しやすさ	比較的簡単	難しい
運用負荷	比較的低い	高い
誤検知・誤遮断	起こり得る	起こりやすい
防御の厳密さ	汎用的な防御に向く	厳密な制御に向く
向いている対象	一般的なWebサイト、CMS、ECサイト	API、管理画面、重要フォーム、決済画面

具体例で見る違い

ログインフォームに、以下のようなリクエストが送信されたとします。

username=admin
password=' OR '1'='1

ブラックリスト方式の場合は、' OR '1'='1 というSQLインジェクションでよく使われる文字列を検知して遮断します。

つまり、判断基準は以下です。

この文字列は攻撃でよく使われるためブロックする。

一方、ホワイトリスト方式の場合は、リクエストが正常なログイン処理の条件に合っているかを確認します。

たとえば、以下のような条件を設定します。

/loginへのPOSTのみ許可
usernameとpasswordのみ許可
想定外のパラメータは禁止
文字数の上限を設定
改行や制御文字は禁止
Content-Typeを指定

この条件に合わない場合、攻撃パターンとして登録されていなくても遮断される可能性があります。

つまり、判断基準は以下です。

正常なログインリクエストの形式ではないためブロックする。

どちらの方式を選ぶべきか

ブラックリスト方式とホワイトリスト方式は、どちらか一方が絶対的に優れているわけではありません。

ブラックリスト方式は導入しやすく、既知の攻撃を広く防ぐのに向いています。

一方、ホワイトリスト方式は、正常な通信条件を厳密に定義できる場合に高い防御効果を期待できます。

そのため、実務では両方を組み合わせる運用が一般的です。

ブラックリスト方式が向いているケース

ブラックリスト方式は、以下のようなケースに向いています。

まずWAFを早く導入したい
一般的なWebサイトを保護したい
WordPressなどのCMSを利用している
既知の攻撃を広く防ぎたい
Webアプリケーションの仕様を細かく把握できていない
複数サイトをまとめて保護したい
運用負荷をできるだけ抑えたい

特に、CMSやECサイト、コーポレートサイト、フォームを持つ一般的なWebサイトでは、ブラックリスト方式のWAFを導入することで、よくある攻撃への基本的な防御を行いやすくなります。

ホワイトリスト方式が向いているケース

ホワイトリスト方式は、以下のようなケースに向いています。

管理画面を厳密に保護したい
決済画面や会員情報変更画面を守りたい
APIのリクエスト仕様が明確に決まっている
入力フォームの項目や形式が固定されている
セキュリティ要件が高いシステムを運用している
アプリケーション仕様を把握している
WAFのログ確認やルール調整を継続できる体制がある

特に、APIや管理画面のように「正常な通信の形」が明確な領域では、ホワイトリスト方式が効果を発揮しやすいです。

実務ではハイブリッド運用が現実的

WAFを実務で導入する場合は、ブラックリスト方式とホワイトリスト方式を組み合わせるのが現実的です。

たとえば、以下のような運用です。

ブラックリスト方式で一般的な攻撃を広く防ぐ
管理画面やログイン画面には厳しめの制限をかける
決済画面や会員情報変更画面にはホワイトリスト方式を適用する
APIにはメソッド、パラメータ、JSONスキーマなどの制限を設ける
検知ログを確認しながら誤検知を調整する
サイト改修や機能追加に合わせてWAFルールを更新する

このように、すべてのページに同じ強度のルールを適用するのではなく、リスクの高い箇所に重点的な対策を行うことが重要です。

重要なページから優先的に保護する

ホワイトリスト方式は強力ですが、全ページに厳密に適用すると運用負荷が高くなります。

そのため、まずは以下のような重要ページから優先的に対策するとよいでしょう。

ログイン画面
管理画面
問い合わせフォーム
資料請求フォーム
会員登録フォーム
決済画面
会員情報変更画面
ファイルアップロード画面
APIエンドポイント

これらのページは攻撃対象になりやすく、被害が発生した場合の影響も大きいため、優先的にWAFルールを調整する価値があります。

WAF導入時の注意点

WAFは便利なセキュリティ対策ですが、導入すればすべての攻撃を防げるわけではありません。

特に重要なのは、WAFは脆弱性そのものを修正するものではないという点です。

WAFは攻撃リクエストを遮断する仕組みであり、アプリケーションのコードや設計上の問題を根本的に修正するものではありません。

そのため、WAFを導入していても、脆弱性修正やセキュアコーディングは必要です。

WAFとあわせて行うべき対策

WAFを有効に活用するには、以下のような対策もあわせて実施する必要があります。

アプリケーションの脆弱性修正
CMSやプラグインの更新
セキュアコーディング
入力値検証
出力エスケープ
認証・認可の適切な実装
パスワード管理の強化
ログ監視
脆弱性診断
セキュリティパッチの適用
バックアップ体制の整備

WAFはあくまで多層防御の一部です。WAFだけに依存するのではなく、アプリケーション、インフラ、運用の各レイヤーで対策を行うことが重要です。

検知モードから始める

WAFを導入するときは、最初から遮断モードにするのではなく、まずは検知モードで運用するのが安全です。

検知モードでは、通信をブロックせずに、どのようなリクエストが攻撃として検知されるかをログで確認できます。

この段階で、以下のような影響を確認します。

正常なフォーム送信が検知されていないか
購入完了や会員登録が妨げられないか
広告流入のURLパラメータが問題にならないか
解析タグやタグマネージャーに影響がないか
外部ツールとのAPI連携が止まらないか
Webhookの受信がブロックされないか

ログを確認し、誤検知を調整してから段階的に遮断を有効化すると、トラブルを抑えやすくなります。

WAF運用では誤検知への対応が重要

WAFを導入すると、誤検知や誤遮断が発生することがあります。

誤検知とは、本来は正常なアクセスであるにもかかわらず、WAFが攻撃と判断してしまうことです。

実際に遮断まで行われた場合は、ユーザーの操作や外部サービス連携に影響が出る可能性があります。

Webマーケティングで起こりやすい影響

Webマーケティングの現場では、WAFの設定によって以下のような問題が起こることがあります。

広告流入用のURLパラメータがブロックされる
LPのフォーム送信が失敗する
問い合わせ完了ページに到達できない
CV計測が正しく行われない
タグマネージャー由来の通信が不審と判断される
CRMやMAツールとの連携APIが止まる
Webhookが遮断される
キャンペーン用の特殊なクエリパラメータが拒否される

このような問題が起きると、セキュリティ面だけでなく、広告効果測定、コンバージョン率、営業活動にも影響します。

そのため、WAF導入時には、セキュリティ担当者だけでなく、開発担当者、インフラ担当者、マーケティング担当者、サイト運用担当者が連携して確認することが重要です。

まとめ

WAFのブラックリスト方式とホワイトリスト方式は、通信を許可・遮断する判断基準が異なります。

ブラックリスト方式は、既知の攻撃パターンや不正な特徴に一致する通信を拒否する方式です。

導入しやすく、一般的な攻撃を広く防ぎやすい一方で、未知の攻撃や難読化された攻撃には弱い場合があります。

ホワイトリスト方式は、あらかじめ定義した正常な通信だけを許可する方式です。

適切に設定すれば高い防御効果を期待できますが、アプリケーション仕様を正確に把握し、継続的にルールを調整する必要があります。

両者の特徴を整理すると、以下のようになります。

方式	概要	強み	弱み
ブラックリスト方式	危険な通信を拒否する	導入しやすく、既知の攻撃に強い	未知の攻撃や回避手法に弱い場合がある
ホワイトリスト方式	正常な通信だけ許可する	厳密な制御ができ、未知の攻撃にも対応しやすい	設定・運用が難しく、誤遮断が起きやすい