目次
WordPressで記事を保存すると403になる。フォームは表示できるのに、送信すると止まる。こうした症状でWAFを無効にすると操作が通り、そのまま無効化を続けてしまうことがあります。必要なのは、止まった原因を確かめ、正規の処理を通しながら防御をできるだけ残す調整です。
この記事は2026年10月18日にWordPressとOWASP Core Rule Setの公式資料を確認した運用ガイドです。特定のWAF製品の設定手順や、新しい脆弱性の速報ではありません。レンタルサーバーのWAF、CDN型の保護、WordPress内の保護機能は設定できる範囲が異なるため、考え方と保守窓口への依頼事項を中心に説明します。
スポンサーリンク
403を見ただけでWAFの誤検知と決めない
403などの拒否は、WAF以外にも、アプリケーションの権限判定、認証の状態、サーバーのアクセス制限などで発生します。WordPressのREST APIでも、操作に必要な権限と認証が求められます。管理者としてログインしているつもりでも、接続の状態や操作対象を確認する必要があります。出典：WordPress公式：REST API Authentication。
本サイトの提案は、操作した画面、時刻、送信先のURL、HTTPメソッド、表示されたエラー、再現条件を記録することです。その時刻のWAFログに一致する拒否があるかを確認し、ログがない場合は別の層も調べます。WAFを一度止めることを、原因特定の唯一の方法にしないでください。
以下は説明用の仮想例です。技術記事にSQLやHTMLの例を入れたときだけ保存に失敗するなら、その本文が検査ルールに反応した可能性はあります。ただし、似た文字列があることだけで誤検知と確定せず、実際のルールIDと検査対象の項目を照合します。
検査する場所と変更する場所を対応させる
通信がCDN、サーバー、WordPressの順に通る構成なら、複数の層が拒否を返す可能性があります。どの管理画面で変更すべきかを間違えると、原因と無関係な防御を弱めることになります。製品名、適用するドメイン、経路、ログの管理者を整理してください。
本サイトでは、まずブラウザーの開発者ツールで失敗したリクエストを特定し、運用担当が保護製品の記録へ対応付ける方法を提案します。レスポンスの見た目だけで製品を断定せず、サーバー事業者や保守会社の説明も合わせます。アクセスIDが付いていれば、その識別子を問い合わせに使えます。
ログの時刻がUTCで、操作した時刻が日本時間という場合もあります。タイムゾーンと時計の差を確認し、同じ秒に複数の通信があれば送信先や識別子で区別します。別のアクセスの拒否を、自分の操作の原因だと取り違えないためです。
スポンサーリンク
ルール全体の除外と入力項目の除外は違う
OWASP Core Rule Setの資料では、ルール全体を除外する方法と、特定の変数を検査から除く方法などを区別しています。また、条件に応じて適用する除外も説明しています。検知したルールをサイト全体で外すことと、特定の処理の一項目だけを外すことでは、防御に空く範囲が変わります。出典：OWASP CRS公式：False Positives and Tuning。
たとえば記事本文の項目で誤検知が起きているなら、本文以外の項目や別のURLまで例外に含める理由を確認します。URI、メソッド、対象項目、該当ルールを絞れるかを検討してください。実際に使える条件は製品ごとに違い、レンタルサーバーでは項目単位の調整を利用者側でできないこともあります。
重要なのは、除外設定が認証や認可を追加するわけではない点です。「管理画面用に見えるURLだから安全」という説明だけでは足りません。そのURLへ未認証で到達した場合や、別の権限の利用者が操作した場合に、アプリケーション側が適切に拒否するかも別に確認します。
例外に期限と見直す条件を付ける
例外の記録には、対象、理由、ルールID、再現した正規の操作、変更前後、担当者、確認日を残します。暫定の除外であれば期限を設け、恒久的に残す場合も、プラグインやWAFルールの更新時に見直す条件を決めてください。
担当者が変わった後に「前からある設定だから消せない」となることを防ぐため、例外を削除すると何が再発するかを説明できる形にします。テストに使った入力そのものに個人情報がある場合は、同じ条件を再現できる無害な値へ置き換え、機密情報を例外管理の資料へ保存しないようにします。
OWASP CRSは、配布されたルールを直接書き換えると更新時に変更が失われ、手作業での維持が必要になる問題を説明しています。利用者がルールを編集できる環境でも、製品が用意した例外の仕組みを検討し、配布物を無断で改変して運用し続けないことが重要です。出典：OWASP CRS公式：ルールを直接変更せずに調整する方法。
スポンサーリンク
本番で防御を止めたまま再現試験しない
再現できる検証環境があれば、そこで調整案を試します。本番固有の保護経路やルールを再現できていない場合は、その限界を記録してください。本番での確認が必要なら、対象と時間、操作する人、元へ戻す手段を決め、保守担当と実施します。
試験には、技術記事の本文や確認用のフォーム入力など、正規の無害なデータを使います。本番へ攻撃コードを大量に投げて「まだ防げるか」を試す方法は、この日常調整の範囲ではありません。防御機能の試験が必要なら、承認した対象と検証用の環境・手順で行います。
製品の検知専用モードも、遮断が続くモードとは異なります。切り替えたことでどの防御が外れるかを確認し、単にログが出るから保護されていると判断しません。利用者が安全な条件で調整できない場合は、無理に変更せず保守窓口へ具体的な再現情報を渡してください。
大きな本文や添付を送ったときだけ失敗する場合は、ルールへの一致以外に、検査対象のサイズ上限やサーバー側の受付上限も確認します。本文を検査しきれない場合の動作は製品ごとに異なるため、単に許容サイズを増やして解決としないでください。受付できる量、検査できる量、アプリケーションが処理できる量を保守担当と対応させます。
また、CDN型のWAFを使う構成では、正規の経路以外から元のサーバーへ到達できないかも管理上の確認事項です。例外を狭く設けたつもりでも、別の入口が保護を通らなければ、その設定だけで全体を説明できません。元サーバーへのアクセス制限は、ヘルスチェックや必要な連携を壊さないよう、事業者の方法に従って検証してください。
保存できた後も一連の操作を確かめる
記事の保存が通っただけでは確認不足の場合があります。下書き、プレビュー、画像追加、公開、公開後の表示まで、変更した経路に関係する操作を確認します。フォームなら、送信後の画面だけでなく、保存先と通知先まで試験用のデータが届くかを見ます。
権限が異なる利用者とログアウト状態も対象です。例外を追加した結果、不要な操作まで成功していないかを確認します。特にAPI連携はブラウザーの操作と経路が異なる場合があるため、実際に利用する連携側でも確認してください。
また、例外に含めなかった処理の検査が有効なことを、設定と製品が提供する検証方法で確認します。検査から外す必要があった項目には、アプリケーション側で行う入力検証、出力時の処理、権限確認を補う課題が残る場合があります。例外を追加したことだけで改善を完了にしません。
保守窓口へは秘密を除いた再現情報を渡す
本サイトの問い合わせ例は、「何時何分、どのURLへどのメソッドで、どの項目を含むと失敗する。WAFログの識別子は何か。対象を限定した例外を利用できるか」という形です。サイト全体のWAFを止めてほしい、と最初から解決方法を固定しない方が、調整の選択肢を残せます。
- 渡す情報：対象ドメイン、時刻とタイムゾーン、失敗したURL・メソッド、ログの識別子、無害な再現例。
- 除く情報：Cookie、Authorizationヘッダー、パスワード、実在する個人情報など、再現に不要な秘密。
- 確認する条件：例外の範囲、反映にかかる時間、戻す方法、更新後に再確認が必要か。
- 完了の記録：正規の処理が成功し、対象外の設定が維持され、担当者が確認したこと。
ブラウザーの通信記録をファイルで出力すると、認証情報や入力内容を含むことがあります。便利な診断資料でも、送付前に内容を確認し、契約上の安全な転送方法を使います。公開のサポート掲示板へ、そのまま添付しないようにしてください。
WAFは更新や権限の見直しを置き換えない
WordPress公式の強化ガイドは、WAFの設置場所としてサーバーやリバースプロキシなど複数の方式を説明しています。ただし、WAFは検査を担当する層であり、プラグインの修正適用や、利用者へ与える権限の管理とは役割が異なります。出典：WordPress公式：Hardening WordPress。
特定の脆弱性への防御ルールがある場合も、修正版の適用方針は別に決めます。ルールが対象とする製品や攻撃条件を確認し、WAFの導入だけで将来のすべての脆弱性まで防げるとは考えません。誤検知の調整中も、更新と権限の課題を忘れないようにします。
安全な調整の目標は、拒否をすべてなくすことではありません。必要な操作を通し、除外した範囲を説明でき、後から見直せる状態にすることです。WAFを切るかどうかの二択から離れ、どの層で何が止まり、どの条件を変えるかを一つずつ確認していきましょう。
スポンサーリンク
