403が出る場面から、確認場所を選ぶ
- 投稿保存や連携だけ403になる
対象のAPIパス・時刻・操作を記録し、読み取りと書き込みを分けます。 確認手順へ - ログインや管理画面だけ拒否される
ログイン制限・IP制限と、直前の設定変更を確認します。 確認手順へ - 公開サイト全体で403になる
広く権限を変更せず、契約先へ状況を伝えて切り分けます。 確認手順へ
403という番号だけでWAFが原因とは決められません。ログと実操作が一致するかを確認してから対処します。
関連：429エラーの確認手順
YOHAKU SELECT / LIVE 403 CASE
実際に書き込みが403になったときの対応
この記事は、WordPressで403 Forbiddenが出たときに、WAF・権限・プラグインなどを最小変更で切り分ける記事です。2026年9月、YOHAKU SELECTでも一部通信が403で拒否されましたが、WAF全体を無効化せず発生時刻・操作・対象REST APIを記録し、WAFログと照合しました。原因不明のHTTPエラーはトラブル解決ロードマップから分岐します。
2026年9月25日には、正常なWPWriter通信がWAFで「SQLインジェクション」として検知されているログを確認。ログと実操作が一致したメディア書き込み系と追加CSS更新系の2通信だけを個別に除外しました。IPアドレス全体やSQLインジェクション検知全体は許可していません。
除外後、直前まで403だった同じメディアアップロードと追加CSS更新を再実行し、どちらも正常に保存できることを確認しました。WAF自体はONのままです。この結果から、このケースでは「WAFを切る」よりログで正常通信を特定し、必要最小限だけ除外する方針が有効でした。
この例はYOHAKU SELECTの環境で起きた事例です。403の原因はサーバー・WAF・プラグイン・権限など複数あるため、同じ対処がすべてのサイトに当てはまるわけではありません。変更の記録は制作・改善ログにも残しています。
1．どこで403が出るかを記録する
サイト全体、管理画面、ログイン、投稿保存、フォーム送信、特定の/wp-json/エンドポイントなど、403が出る場所によって原因候補が変わります。エラーが出た時刻とURLを控えてください。
相談前の記録テンプレートを開く
下のひな形を選択して、ご自身のメモへコピーしてください。この欄から送信・保存はされません。確認できない項目は「未確認」と残します。
パスワード・認証情報・個人情報・復旧リンクは書き込まず、相談先には必要な内容だけを伝えます。
2．WAFのブロックログを確認する
共有サーバーではWAFがSQLインジェクション、WebDAV、異常なリクエストなどとして正規のWordPress操作を誤検知することがあります。ログに該当時刻のブロックがある場合は、ホスティング会社の案内に沿って対象ルールを確認します。
3．WAF全体を無効にしない
原因確認のため一時的な切り分けを行う場合でも、恒久的にWAF全体をOFFへするのは避けます。可能なら該当URLやルールだけを対象に調整し、変更後に再度保護状態を確認してください。
4．プラグインとセキュリティ設定を確認する
ログイン制限、IP制限、REST API制限、キャッシュ、セキュリティプラグインの変更後から発生した場合は、直前の変更が原因候補です。複数を同時に無効化せず、1つずつ確認します。
5．ファイル権限は推測で変更しない
ファイルやディレクトリの権限が不適切な場合も403の原因になりますが、権限値をむやみに緩めるとセキュリティリスクが上がります。ホスティング側の推奨値を確認してください。
6．REST APIだけ403になる場合
投稿保存やブロックエディター、プラグイン連携では/wp-json/以下のREST APIが使われます。特定エンドポイントだけ403なら、WAFやREST API制限のログを確認します。
JSONレスポンスエラーの確認、WordPressのセキュリティ対策も関連します。403ではなく通信がタイムアウトしている場合は、cURL error 28の確認手順へ進んでください。
403以外の症状も含めて切り分ける場合は、WordPressトラブル解決ロードマップから症状を選んでください。設定変更の前に、WordPressのバックアップと復元の基本で戻せる状態を確認し、更新直後の不具合ならWordPress更新前後の確認手順もあわせて確認してください。
403エラーの切り分け早見表
| 403が出る場面 | 確認する場所 |
|---|---|
| 管理画面の保存・更新だけ失敗 | WAFログ、REST API、セキュリティ設定 |
| ログイン画面だけ403 | IP制限、ログイン保護、WAF |
| 特定URLだけ403 | そのURLに対するWAF検知・アクセス制御 |
| サイト全体が403 | サーバー側アクセス制限、権限、設定変更 |
ConoHa WINGで確認するとき
ConoHa WINGを利用している場合は、403が出た時刻と操作を控えたうえでWAF設定・ログを確認します。WAF全体を長時間OFFにするより、該当リクエストだけを特定する方が安全です。ConoHa WING公式：WAF設定
やってはいけない対処
- 403が出たという理由だけでWAFを恒久的にOFFへする
- ファイル権限を必要以上に緩くする
- 複数のセキュリティ設定を同時に変更する
1つずつ変更し、変更前後で同じ操作を再現できるか確認するのが基本です。
サポートへ相談する目安
403が特定の操作だけで起き、WAFログに同時刻の記録がある場合は原因を絞りやすい状態です。サイト全体が403になる、管理画面にも入れない、権限変更が必要、WAFログを見ても原因が分からない場合は、URL・発生時刻・操作内容をまとめてホスティング会社へ相談してください。
よくある質問
403と404は同じですか？
異なります。404は主にページが見つからない状態、403はサーバー側がアクセスを拒否している状態です。
WAFの除外は危険ですか？
範囲によります。YOHAKU SELECTでは、発生時刻・操作・対象URLがWAFログと一致した正常通信だけを個別に除外し、WAF本体はONのまま運用しています。SQLインジェクション検知全体や送信元IP全体をまとめて許可するのではなく、実操作と一致した必要最小限の通信だけを対象にし、除外後は同じ操作を再実行して正常化したか確認します。
参考情報
NEXT / RELATED
