2026.09.10

【WordPress】WAFの誤検知で管理画面が保存できない時の対処法｜止めない・消さない・正しく除外する

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 管理画面で「保存」した瞬間に403エラーが出る場合、WAFが正規の更新を攻撃と誤検知している可能性が高い。
– WAF全体をオフにするのではなく、該当シグネチャと自分のIPだけを一時的に除外するのが安全な対処法。
– 除外後は操作が完了次第、設定を元に戻し、毎回の403でWAFを「壊れたもの」と片付けないことが大事。

「保存」を押した瞬間に403——あるあるの現場

「記事を更新して保存ボタンを押したら、急に『403 Forbidden』と表示された」
「プラグインの設定を変えようとしたら、画面が真っ白になった」

Webサイト保守の現場で、この相談は本当に頻繁に来ます。しかも特徴的なのは、普段は問題なく更新できていたのに、特定の操作だけが弾かれるという点です。記事のタイトル変更はできるのに、本文にコード片を貼ったら403。設定画面の保存はできるのに、プラグインの有効化だけが失敗。この「一部の操作だけが死ぬ」症状は、WAF（Webアプリケーションファイアウォール）の誤検知である可能性が高いのです。

403で保存できない様子のイメージ

WAFはなぜ「味方の操作」を敵と誤認するのか

WAFの仕組みはシンプルです。送られてくるリクエスト（保存される本文や設定値）を、攻撃パターンのリスト（シグネチャ）と照合して、危険そうなものを遮断します。

ここで問題が起きます。WordPressの管理画面では、記事本文にHTMLタグやSQL風の文字列、URLパラメータを含むことが珍しくありません。例えば:

記事本文に <script> タグや iframe の埋め込みコードを書いた
SQLの説明として UNION SELECT という言葉を載せた
設定値に ../ や %00 などの記号列が入った

これらは正常な業務上の入力ですが、攻撃コードと同じ形をしているため、WAFからは区別がつきません。結果として「管理画面からの正規の保存リクエスト」が攻撃と見なされ、403で遮断される。セキュリティ機能が仕事をしすぎている状態です。

視点を変えると分かりやすいのですが、WAFが反応しているということは、少なくともWAFが生きて仕事をしているということです。何も遮断しなくなったWAFより、誤検知するWAFの方がまだ安全側です。だからこそ「丸ごと止める」ではなく「正しく除外する」のが正解なのです。

やってはいけないこと：WAF全体をオフにして放置

誤検知に直面したとき、多くの人が最初にやるのは「WAFを無効化する」です。レンタルサーバーのコントロールパネルでWAF設定をオフにすれば、たしかに403は消えます。保存もできるようになります。

しかし、これはサイトを防御装置ごと外に出した状態にするのと同じです。

WAFが止まっている間は、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃が素通りする
「とりあえずオフ」のまま放置されるケースが非常に多い。私たちの復旧現場でも、攻撃を受けたサイトの多くがWAF無効のままでした
管理画面はインターネット上の誰でもログインURLに到達できる場所なので、無防備な期間が長いほどリスクが積み上がる

IPA（情報処理推進機構）の「情報セキュリティ10大脅威」でも、Webサイトへの攻撃は毎年のように上位にランクインしています（出典：IPA「情報セキュリティ10大脅威」）。誤検知を理由に防御を外すのは、火事の心配をされたから消火器を捨てるようなものです。

正しい対処：シグネチャとIP単位で「一時的に」除外する

安全な対処の基本は、「全部」ではなく「該当箇所だけ」を、必要な期間だけ除外することです。手順を整理します。

除外設定の流れ

ステップ1：誤検知の確定と記録

まず、本当にWAFが原因かを確定します。

WAF設定画面に検知ログ（遮断ログ）があれば、該当時刻・該当URL・シグネチャIDを記録する
ログが見られない場合でも、「普段はできて特定操作だけ403」という症状があればWAF誤検知を疑ってよい

シグネチャIDと遮断URLが分かっていると、後の除外設定と誤検知報告が格段にスムーズになります。

ステップ2：自分のIPアドレスを一時的に除外（最小範囲から）

多くのWAFには「特定IPからのリクエストを遮断対象外にする」設定があります。

除外対象は「自分のIPだけ」で最小限にする
固定IP契約でない場合、自宅回線のIPは変わることがあるため、作業中だけ有効にして完了したら解除する

IP単位の除外なら、他の訪問者や攻撃への防御はWAFがそのまま働き続けます。ここが「全体オフ」との決定的な違いです。

ステップ3：該当シグネチャの除外

IP除外でも保存できない場合（複数人での更新や、シグネチャ単位の誤検知が確定している場合）は、シグネチャ単位の除外を使います。

ロリポップ！をはじめ多くのレンタルサーバーでは、WAF設定画面でシグネチャ単位の除外（検知設定の解除）が可能です。検知ログに記録されたシグネチャを指定して除外します（詳しい手順はお使いのサーバー会社の公式マニュアルをご確認ください）
除外するのは「記事保存で誤検知する1つのシグネチャ」に絞る。複数まとめて解除しない
除外設定の反映には時間がかかることがある。すぐ反映しなくても焦らない

ステップ4：操作が終わったら必ず元に戻す

ここが一番大事な落とし穴です。

必要な保存・更新が完了したら、除外設定を解除してWAFをフルに戻す
「毎回の手間が面倒だから」という理由で除外を放置するのが、後日の事故につながります
本来は「この操作が毎回誤検知する」状態を放置せず、サーバー会社に誤検知報告を入れるのが理想です。報告が多く寄せられたシグネチャは、ベンダー側で精度が改善されることがあります