WAFが正常なリクエストを遮断するとき、例外ルールをどこまで許容するか

課題と判断基準

Webエディターで文書を保存すると、403応答が返ってきます。ログインと閲覧は正常で、特定の内容を入力したときだけ保存に失敗します。そのパス全体を許可すれば、業務を再開できるかもしれません。しかし、どの検査が実行されなくなったのかは別の問題として残ります。

正常動作と衝突する検査を特定し、WAFの例外を必要なリクエストとルールだけに限定します。適用前に維持する防御と切り戻し条件を決め、一時的な例外には担当者、再確認時刻、有効期限を設定することを勧めます。 遮断数が減ったという事実だけでは変更は完了しません。正常機能が復旧し、例外の対象外のリクエストと残りのセキュリティ制御も意図どおりに処理されることを確認します。

本稿は、2026年9月26日に確認した公式文書に基づく運用ガイドです。製品の動作は各文書の適用範囲で説明し、承認、有効期限、検証の手順はチームで定める運用設計として提案します。事例と変更記録はいずれも設計例であり、実際の顧客インシデントやテスト結果ではありません。

まず、403を返した層を確認します

403は、オリジンWebサーバーのアクセス制限やアプリケーションの認可検査でも発生します。Cloudflareも、WAF以外のセキュリティ機能や一部の接続処理で403を返します。応答コードや遮断画面のロゴだけで、WAFの誤検知と断定してはいけません。^[1]

調査は、各層で同じリクエストを見つけて関連付けることから始めます。

層ごとに識別子が異なる場合は、まず対応関係を確認します。値が同じはずだと仮定したり、時刻が近いという理由だけで別のリクエストを結び付けたりしません。リクエスト全体を貼り付ける代わりに、メタデータと機密情報を除いた再現資料を使います。

特に、ルールに一致した記録と、最終的な遮断原因は異なります。 AWS WAFのログは、最終アクション、終了ルール、ルールグループ内の一致情報、非終了の一致情報を区別します。グループ名だけを確認し、その中のどのルールが遮断したのかを見落とさないようにします。^[2]

ログがないという理由だけでWAFを原因から除外するのも早計です。Cloudflare Security Eventsは全受信リクエストの一覧ではなく、サンプリングが適用される場合も、1件のリクエストから複数のイベントが生じる場合もあります。検索時間帯とフィルターを絞り、必要に応じて他のリクエストログと照合します。イベント件数をそのまま利用者のリクエスト数として数えません。^[3]

「正常なリクエスト」である根拠を先に揃えます

利用者が送信したことやログイン済みであることだけで、内容も安全だとは判断しません。まず、アプリケーションが許可すると決めた動作を確認します。文書本文で限定的なHTMLを許可するのか、その利用者に文書の編集権限があるのか、サーバーが実際に同じ入力契約を適用しているのかが判断基準です。

OWASP Core Rule Set（CRS）は、個別アプリケーションの業務文脈を知らない汎用検知ルールが、正常な入力と衝突する場合があると説明しています。誤検知ログ自体にパスワードなどの機密情報が含まれる場合もあるため、元のリクエストを公開Issueや共有文書にコピーする方法は避けます。^[4]

本稿では、例外を検討するための最低限の証拠として、機密情報を除いた入力を使い、許可されたテスト環境で失敗を再現することを提案します。どのフィールドがどのルールと衝突するのかを説明し、業務契約上その入力が許可されることの確認と、アプリケーションの関連するセキュリティ処理の根拠を残します。例外適用後は、HTTPの成功応答だけでなく、実際の保存と再取得の結果まで確認します。

この証拠がなければ、例外を広げるより原因調査を続けます。脆弱な入力処理をWAFが代わりに遮断している場合と、正常入力の誤検知では、対応を変える必要があります。

リクエストの範囲を絞ることと、利用者を信頼することは別です

例外の範囲は「サイト全体」より、「このホストのこのパスに、このメソッドで入るリクエスト」に近付けます。製品とエンジンが対応するなら、原因となったフィールドとルールまで絞ります。パスやメソッドの条件は、例外を適用するリクエストの選択条件であって、安全性の証明ではありません。

認証の文脈を条件に使う場合は、WAFの評価時点で、検証済みのID情報が実際に利用可能かを確認します。クライアントが設定できるX-Trustedのようなヘッダー、任意のパラメーター、セッションクッキーの存在だけで「認証済みリクエスト」とは扱いません。特定の国やIPであるという理由だけで残りの検査をすべて省く方法も、本稿の基本案には含めません。

WAFより前でIDを検証できない構成なら、例外が未認証リクエストにも適用されることをリスク記録に明記します。アプリケーションの認証と認可の検査は維持します。OWASPも、リクエストごとに認可を確認し、明示的に許可していないアクセスはデフォルトで拒否することを推奨しています。^[5]

製品ごとに「例外」が省く対象は異なります

CRSでは、特定ルールの検査対象からフィールドを除外できます

CRSの文書は、ルール全体の除外と、特定の変数だけを検査対象から外す方法を区別しています。条件付きの実行時例外を使えば、特定のリクエストに対する特定ルールの検査対象だけを調整できます。ただし、エンジンとルール構造の制約があります。チェーンルールのすべての段階で任意のフィールドを除外できるわけではなく、設定時例外と実行時例外では配置順序も異なります。配備済みのCRSルールファイルを直接変更せず、別の例外設定として管理します。^[4]

Cloudflareでは、一致したリクエストで選択ルールをスキップします

Cloudflare Managed Rulesの例外では、一致条件とスキップするルールまたはルールセットを指定します。したがって、パスを限定して特定の管理ルールをSkipする変更と、そのルールが検査する複数フィールドのうち1つだけを外す変更は同じではありません。アカウントレベルとゾーンレベルの適用範囲も区別します。後から評価されるゾーンレベルの例外で、先に行われたアカウントレベルの遮断を取り消すことはできません。^[6]

Custom RulesのSkipは、選択内容によって、管理ルールだけでなくRate LimitingやSuper Bot Fight Modeなどの評価も省けます。名称が似ているBot Fight Modeは、同じ方法ではスキップできません。画面で選んだ対象を変更記録に正確に記し、例外リクエストのログ記録も確認します。Skipルールのログを無効にすると、そのリクエストがSecurity Eventsに表示されない場合があります。^[7]

AWS WAFのCountは、検査を省く機能ではありません

AWS WAFのCountは、ルールへの一致を記録して後続評価を続ける非終了アクションです。AllowはそのWeb ACLの評価を終了するため、後続のWAFルールの検査を維持する代替策ではありません。また、ルールグループの戻りアクションだけをCountにすることと、グループ内の個別ルールをCountにすることも異なります。前者はグループ内部の評価フローを変えません。^[8]

AWSが説明する例外処理には、個別ルールをCountに変更し、そのルールが付与するlabelを後続ルールで使う方法があります。遮断ルールを調整するなら、「そのlabelがあり、狭い例外条件には該当しないリクエスト」を後続で遮断するように設計できます。labelが実際に付与されるか、正確な名称と評価順序を確認します。後続の遮断を入れ忘れると、例外対象外のリクエストまで防御が弱まります。^[9]

一方、管理ルールグループのscope-down statementは、グループに入るリクエスト自体を制限します。グループに入らないリクエストは、その中の他のルールでも評価されません。1つのフィールドやルールだけを除外する設定として扱ってはいけません。^[10]

この違いがあるため、ベンダーを変更するときに例外条件の文字列だけを移してはいけません。例外に入るリクエスト、省かれる検査、維持される検査を一緒に比較します。

例外の変更記録を作成します

次は、限定的なHTMLを許可する文書編集機能の設計例です。自社運用のCRSで、該当ルールのフィールド単位の除外が可能だと仮定しています。R、A、Bは説明用の識別子であり、実際のルールIDや配備バージョンではありません。CloudflareやAWS WAFへそのまま移せる設定ではありません。

補完制御は、失った防御と同じリスクを扱う必要があります。XSS検査を外してレート制限だけを追加しても、同じリスクは補えません。HTML入力が必要な機能には適切なHTMLサニタイズが必要で、通常の文字列には出力位置に合ったエンコードが重要です。OWASPは、WAFをアプリケーションのXSSの根本原因を解消する手段とは位置付けていません。^[11]

各制御の役割を整理するには、WAF・API Gateway・Rate Limit・Schema Validation・JWT・mTLSの役割比較も参照できます。

正常なリクエストだけでなく、例外の境界も再検証します

検証は、自ら所有するか、明示的に許可されたテスト環境で行います。実際の顧客トークンや本番リクエスト本文は移さず、必要な特徴だけを保持した合成入力を使います。次の表は、先の事例の期待結果を定める設計例であり、実行完了報告ではありません。

この検証で「遮断すべき」という結果をすべてWAFの403に統一しません。認可検査はアプリケーションが拒否し、HTMLサニタイズは安全な値への変換として動作する場合があります。どの層がどの結果に責任を持つかを先に定めることで、誤った合格判定を避けられます。

チームの変更記録には、選んだテストだけでなく、除外した項目と理由も残します。記録様式が必要なら、既存の変更別回帰テスト範囲決定ワークブックを使い、WAF例外によって追加した境界とセキュリティ上の期待結果を関連付けます。

限定適用後は、遮断数だけでなく機能と防御を一緒に観測します

テストに通ったからといって、サイト全体へ例外をコピーしません。原因を確認した機能とパスへ先に適用し、誰が観測し、どの条件で中止するかを決めます。AWSも本番適用前のテストと調整を推奨し、設定変更の伝播中は一時的に動作が異なる場合があると説明しています。変更APIの成功応答と、すべての観測箇所で新しいポリシーが動くことの確認は区別します。^[12]

観測対象には、例外に一致したリクエストの範囲、該当業務の成否、例外外の遮断、アプリケーションの認証・入力エラーを含めます。遮断件数だけが下がった場合、検査が減ったのか、実際の誤検知が減ったのかはまだ分かりません。サンプルイベントから全体の誤検知率を計算したり、スキップした検査で検知がないことを安全の証拠にしたりしません。

有効期限は、ルールの説明欄に日付を書くだけでは機能しません。自動削除機能や承認済みの自動化があるなら、実際の動作と失敗通知を確認します。ない場合は、担当者に削除・再承認の作業と確認手順を割り当てます。すべてのWAFが例外を自動失効させるとは仮定しません。 ここで提案する期限は、組織の運用制御です。

例外を削除すると、元の正常リクエストの遮断が再発する場合もあります。その場合も全面許可へ広げず、リスクを再評価し、必要なら機能を制限するか代替の業務経路を提供します。緊急例外が不可欠でも、承認者、範囲、終了条件は残します。

カレンダー上の期限より前でも再確認が必要になる場合があります。パス、メソッド、パーサー、認証フロー、ルールセットが変わったら、既存例外の根拠を再確認します。Cloudflareの2026年9月22日の変更履歴にも、管理ルールのアクションをLogからBlockへ変更した項目があります。アプリケーションコードが同じでも、セキュリティルールの動作は変わります。^[13]

アプリケーションを直すべき問題を例外で覆いません

入力形式がサーバーの契約に反する、HTMLを安全に処理せず保存・出力する、認可検査が欠けている場合は、まず設計を修正します。逆に、業務上必要な正常入力を一律に削除して誤検知をなくすことも、適切な解決ではありません。許可する入力と安全な処理方法を定めたうえで、例外の必要性を判断します。

検査を避ける目的で別のエンコードや不透明なデータに内容を隠す変更は、本稿の解決策には含めません。例外が必要でも、検知を避けられたという事実ではなく、許可する動作と補完制御の検証によって正当化します。

元のルールが防いでいたリスクを説明できない、必要な補完制御がない、実装が意図した最小範囲より大幅に広い、観測と切り戻しの担当者がいない場合は、例外の維持を承認しない基準を勧めます。安全な運用条件を整えられなければ、機能を一時的に制限する選択も検討します。

WAF例外の変更が終わるのは、利用者の保存ボタンが再び動いた瞬間ではありません。正常機能の復旧、維持する防御、例外の削除または再承認まで確認したときに変更を閉じられます。

ルール、ログ、切り戻しの責任が複数チームに分かれているなら、IXCのWAF・DDoS防御サービスのルール設計・運用範囲を確認し、内部で担う仕事と支援を受ける仕事を分けられます。