WordPressのmod_securityエラーを修正する方法：6つの簡単な方法

WordPress サイトでの作業中に 403 Forbidden などの mod_security エラーが発生すると

多くの場合、これらのエラーは、Web サイトのコードの問題やプラグインの誤動作を示すものではなく、 ModSecurity。

このガイドでは、これらの問題の診断と解決について詳しく説明し、サイトが正しく機能しながら安全な状態を維持できるようにします。.

TL;DR: WordPressのmod_securityエラーのクイックフィックスガイド

• mod_security エラーは通常、サイトが壊れているのではなく、サーバーのファイアウォールが正当な WordPress アクティビティをブロックしたときに発生します。.

• 変更を加える前に、必ずサーバーログを確認し、正確なルールIDを確認してください。これにより、不要なセキュリティリスクを回避できます。.

• 最も安全な解決策は、ModSecurity を完全に無効にするのではなく、ホスティング プロバイダーに特定のルール ID をホワイトリストに登録するよう依頼することです。.

• バックアップとステージング サイトを使用して修正を安全にテストし、SecRuleRemoveById などの対象を絞ったルールの削除を適用して、ファイアウォールをアクティブかつ安全な状態に保ちます。.

WordPressのmod_securityエラー：概要と根本原因

ModSecurity は高度なファイアウォールですが、人間の管理者のようなコンテキスト認識機能がありません。.

これを修正するには、まずそれが何であるか、そしてなぜ正当な WordPress アクティビティを脅威としてフラグ付けするのかを理解する必要があります。.

ModSecurity プロジェクトとは何ですか? また、Web アプリケーション ファイアウォールとしてどのように機能しますか?

Web サーバー (通常は Apache、Nginx、または IIS) 上で直接実行されるオープンソースのWeb アプリケーション ファイアウォール (WAF)

これはインターネットと Web サイトの間に位置し、すべての受信HTTP要求と送信応答を検査します。

主な機能は、事前定義されたルールに従ってトラフィックをフィルタリングすることです。ホストで使用される最も一般的なWAFルールセットは、OWASP CRS（コアルールセット）です。.

訪問者のリクエストがSQL インジェクションの試みや悪意のあるボットなどの既知の攻撃パターンと一致する場合、ModSecurity エンジンはリクエストを直ちにブロックします。

このプロアクティブな保護は、一般的な脅威や HTTP 攻撃からホスティング環境を守るために不可欠です。.

WordPressサイトでよくあるmod_securityエラー

ModSecurityがリクエストをブロックした場合、明示的に通知されることはほとんどありません。代わりに、ブラウザに標準的なサーバーエラーコードが表示されます。

• 403 Forbidden:サーバーはリクエストを理解しましたが、処理を拒否しました。これは、セキュリティルールがトリガーされたときに最もよく発生するエラーです。

• 406 許容不可:これは、要求されたリソースが、リクエストで送信されたヘッダーに対応する応答を生成できない場合に発生します (多くの場合、特定のブラウザ ヘッダーまたは Cookie データによってトリガーされます)。

• 500 内部サーバー エラー: ModSecurity を制御しようとする .htaccess ファイルの設定ミスにより、サイト全体がクラッシュする可能性があります。

• ログイン ループ:ルールによって認証プロセスにフラグが立てられると、WordPress ユーザーはログインできなくなり、エラー メッセージが表示されずにログイン ページにリダイレクトされ続けることがあります。

mod_security が WordPress で誤検知を生成するのはなぜですか?

ModSecurityはパターンマッチロジックに依存しています。管理者であることを「認識」せず、コードとテキスト文字列のみを認識します。そのため、安全なアクションがブロックされる誤検知が発生することがよくあります。

• 疑わしい SQL キーワード:データベース管理に関するブログ記事を書くときに、テキスト内で DROP TABLE や SELECT * などの用語を使用すると、ModSecurity によってこれが SQL インジェクション攻撃と解釈され、「公開」アクションがブロックされる可能性があります。

• プラグインデータ：新しいプラグインやSEOプラグインは、複雑なデータ（JSONまたはXML）をサーバーに送信することがよくあります。このデータにエクスプロイトに類似する特殊文字や構造が含まれている場合、ファイアウォールによってブロックされます。

• 誤検知:クロスサイト スクリプティングを防ぐための厳格なルールに誤って一致する可能性があります。

修正を適用する前にWordPressのmod_securityエラーを診断する

セキュリティ機能を盲目的に無効化するのは危険です。修正を適用する前に、エラーを正しく診断し、ModSecurity が実際に原因となっていることを確認する必要があります。.

ブラウザのエラーメッセージとエラーが発生したURLを正確に記録する

まずエラーを注意深く観察します。.

• エラーをトリガーする:ブロックの原因となるアクションを実行します (例: 特定のページを保存する)。

• URLを確認してください：アドレスバーを確認してください。エラーはwp-admin/post.phpで発生していますか？それとも特定のプラグインのURLで発生していますか？

• コードをメモします: 403、406、それとも 500 エラーですか?

特定のアクション（たとえば、投稿コンテンツから特定のコード スニペットを削除するなど）を停止するとエラーが消える場合は、コンテンツ フィルターが原因である可能性が高くなります。.

ホスティングコントロールパネルまたはSSHでModSecurityログにアクセスして分析する

具体的な原因を特定するには、ログを確認する必要があります。多くのホスティングプロバイダーでは、コントロールパネルまたはSSH経由でログを表示できます。.

• cPanel:ログインし、「メトリクス」または「セキュリティ」セクションに移動します。「エラーログ」または「ModSecurityログ」を探します。

• SSH:ターミナルにアクセスできる場合、ログ ファイルは通常、/usr/local/apache/logs/error_log または /var/log/httpd/error_log にあります。

ファイルを開き、「ModSecurity」またはIPアドレスを検索してください。「ModSecurity: Access denied」という行を探してください。

さらに読む: WordPressで「申し訳ありませんが、このページへのアクセスは許可されていません」というエラーを修正する方法

ModSecurity監査ログでトリガールールIDを特定する

これは最も重要なステップです。ログエントリでルールIDを探してください。通常、ルールIDは括弧で囲まれて表示されます（例：[id “941160”]）。.

ログスニペットの例: ModSecurity: コード 403 でアクセスが拒否されました… [メッセージ “NoScript XSS InjectionChecker: HTML インジェクション”] [ID “941160”]

この例では、941160がルールIDです。この番号を書き留めておいてください。これにより、ファイアウォール全体を無効にするのではなく、後でこの特定のルールだけ

ステージングWordPressサイトでmod_securityエラーを再現する

実際のサイトでセキュリティの変更をテストしないでください。.

• ホストのツールまたはプラグインを使用して、Web サイトのステージング クローンを作成します。.
• ステージングサイトでエラーを再現してみます。.
• そこでエラーが発生した場合は、メイン サイトの可用性を損なうことなく、以下の修正を安全にテストできます。.

詳細: WordPressで301エラーを修正する方法

WordPressのmod_securityエラーを修正する方法

ルール ID を取得したら (または ModSecurity の問題であることを確認したら)、次のいずれかの方法を使用します。.

方法1: ホスティングプロバイダーに特定のModSecurityルールIDをホワイトリストに登録するよう依頼する

これは最善かつ最も永続的な解決策です。ほとんどの共有ホスティングプロバイダーは、ModSecurityコアファイルを編集するためのルートアクセス権限を付与していないため、プロバイダーに申請する必要があります。.

• サポート チケットを開きます。.

• テンプレート: 「こんにちは。サイトで403エラーが発生しています。エラーログによると、ModSecurityルールID [ここにIDを挿入] によってトリガーされています。これは、私の正当なWordPressアクティビティによる誤検知です。このルールを私のドメイン？」

• サポート スタッフは通常、数分でこの例外をサーバー構成に追加できます。.

方法2: テストのためにcPanelでmod_securityを一時的に無効にする

行き詰まってサポートを待てない場合は、ModSecurity を一時的にオフにしてタスクを完了することができます。.

• cPanel にログインします。.
• 「セキュリティ」→「ModSecurity」に移動します。.
• リスト内でドメインを見つけます。.
• トグルをオンからオフに切り替えます。.

注:これによりファイアウォールが完全に無効化されます。設定の保存など、タスクを完了するために必要な数分間のみ実行し、その後は一般的な脅威から保護するためにすぐにファイアウォールを再度オンにしてください。

方法3: mod_securityエラーを引き起こすプラグインまたはテーマの競合を修正する

場合によっては、サイト上のソフトウェアのコーディングが不適切であることが問題となることがあります。.

• プラグインの競合：プラグインを1つずつ無効化してください。特定のプラグインを無効化した後にエラーが解消された場合は、プラグインのアップデートが利用可能かどうかを確認してください。アップデートがない場合は、プラグインの開発者に連絡してください。商用WAFベンダーによるフラグ付けを回避するために、プラグインのデータ送信方法を調整する必要があるかもしれません。

• テーマの問題：一時的にWordPressのデフォルトテーマ（Twenty Twenty-F​​ourなど）に切り替えてみてください。エラーが解決した場合、元のテーマにブロックの原因となるカスタムスクリプトが含まれている可能性があります。

さらに詳しく: 409 競合エラーとは何か、そしてそれを修正する方法

方法4: .htaccessルールを変更してmod_securityのブロックを解決する

ホストが .htaccess のオーバーライドを許可している場合は、サイトの ModSecurity を手動で無効にすることができます。.

• FTP またはファイル マネージャー経由でサイトにアクセスします。.
• ルート フォルダーで .htaccess ファイルを見つけます。.
• 先頭に次のコードを追加します。

<IfModule mod_security.c>SecFilterEngine オフ SecFilterScanPOST オフ</IfModule>

注:すべてのサーバーがこのディレクティブをサポートしているわけではありません。このディレクティブを追加した後にサイトがクラッシュ（エラー500）した場合は、直ちに削除してください。

方法5: ApacheまたはNGINXサーバー構成でSecRuleRemoveByIdを使用する

VPS または専用サーバー(またはホストがこの特定の .htaccess ディレクティブをサポートしている場合)、先ほど見つけた ID を使用してブロック ルールを意図的に削除できます。

• Apache (.htaccess) の場合:次の行を .htaccess ファイルに追加し、XXXXXX をログの ID に置き換えます。

<IfModule mod_security.c>SecRuleRemoveById XXXXXX</IfModule>

• Nginxの場合： nginx.confまたはサイトのvhostファイルを変更するには、通常、root権限が必要です。serverまたはlocationブロック内に以下を追加してください。

modsecurity_rules 'SecRuleRemoveById XXXXXX';

これは、他のすべての脅威に対してファイアウォールをアクティブな状態に保つため、方法 4 よりも優れた方法です。.

続きを読む: Apache vs Nginx

方法6：ファイアウォールの競合を避けるためにセキュリティプラグインを再設定する

Wordfence 、 JetPackのプラグインを実行すると、アプリケーションレベルのファイアウォールとして機能します。これらのプラグインを、厳格なサーバーレベルのModSecurity設定と併用すると、「二重フィルタリング」が発生し、有効なリクエストがブロックされる可能性があります。

• セキュリティ プラグインの「学習モード」または「ホワイトリスト」の設定を確認してください。

• プラグインとサーバーの両方で、インターネット サービス プロバイダーまたは動的 IP が過度に積極的な設定によってフラグ付けされていないことを確認します。.

さらに詳しく: WordPressの混合コンテンツエラーを修正する方法

バックアップとWordPressステージングを使用した安全なトラブルシューティングワークフロー

サーバーレベルのセキュリティ ルールを変更したり、コア構成ファイルを編集したりすると、重大な固有のリスクが伴います。.

.htaccess ファイルに構文エラーが 1 つあるだけで、即座に「500 内部サーバー エラー」が発生し、Web サイト全体がオフラインになる可能性があります。.

予期しないダウンタイムやデータ損失を回避するには、次の安全なトラブルシューティング ワークフローに厳密に従う必要があります。

• バックアップ：コードに触れる前に、ウェブサイトの完全なバックアップを手動で作成してください。WordPressの両方をダウンロードして。これにより、万が一何か問題が発生した場合に備え、すぐに復元できるポイントが作成されます。

• ステージング：ファイアウォールの変更は、本番環境でテストしないでください。サイトのステージングクローンを作成してください。多くの最新ホスティングプロバイダーがこの機能を提供しています。まずは、この隔離されたサンドボックスで、すべての診断テストと設定ファイルの編集を実行してください。

• 検証：修正（SecRuleRemoveByIdなど）を適用した後は、徹底的なテストが必要です。元のエラーが解消されたかどうかを確認するだけでなく、お問い合わせフォーム、ログインページ、eコマースのチェックアウトフローなどの重要な機能をテストし、セキュリティ変更によって他のスクリプトが誤って破損していないことを確認してください。

• デプロイ:ソリューションがステージングで副作用なしで検証されたら、まったく同じ修正をライブ サイトに安全に適用できます。

結論: WordPressのmod_securityエラーを解決する

ModSecurityはアプリケーションセキュリティに不可欠なコンポーネントであり、レスポンスのフィルタリング機能を提供し、 WordPressインストールに。しかし、適切な設定が問題を回避する鍵となります。

エラー ログを分析し、特定のルール ID を識別し、対象を絞ったホワイトリスト ルールを適用することで (ファイアウォールを完全に無効にするのではなく)、自分とユーザーにとってスムーズに機能する安全なホスティング環境を維持できます。.

.htaccess 経由で修正する場合でも、ホスティング プロバイダーに問い合わせて修正する場合でも、専門家のアドバイスを受け、体系的なアプローチに従うことが、これらのエラーを永続的に解決する最善の方法です。.

WordPressのmod_securityエラーの修正に関するよくある質問