WordPressの外部HTTP通信はWP_HTTP_BLOCK_EXTERNALとWP_ACCESSIBLE_HOSTSで制限する
公開日: 執筆:佐藤
WordPressから外部へのHTTP要求を制限するなら、先に必要な接続先を洗い出します。その後でWP_HTTP_BLOCK_EXTERNALにより外部ホストへの要求を止め、WP_ACCESSIBLE_HOSTSへ必要なホスト名だけを指定します。
二つの定数を先に追加し、止まった機能を見つける方法は採りません。WordPress本体の更新確認、プラグインやテーマの外部機能、定期処理が使う接続先と担当を一覧にしてから、確認用の環境で設定します。
WP_HTTP_BLOCK_EXTERNALは外部ホストへの要求を止める
wp-config.phpで次の定数をtrueにすると、WordPressのHTTP処理は外部ホストへの要求を拒否します。
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
WP_Httpの要求処理は、拒否した要求を送信せず、http_request_failedというWP_Errorを返します。呼び出した機能がこのエラーを表示するか、記録するか、何も表示せず処理を終えるかは、その実装によって変わります。
標準では、localhostと、WordPressアドレスに設定されたホストへの要求は止めません。同じサイトへ送る要求と、別のホストへ送る要求を分ける設定です。ただし、サイトと同じドメインにあるすべてのURLが安全だと判定する機能ではありません。許可の単位はホストです。
WP_ACCESSIBLE_HOSTSは必要なホストだけを許可する
外部要求を止めた状態で、接続が必要なホストをWP_ACCESSIBLE_HOSTSへ指定します。複数ある場合はカンマで区切ります。
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org' );
この例では、標準で許可される自サイトとlocalhostに加え、api.wordpress.orgへの要求を許可します。WordPressの更新確認処理は、このホストへ本体、プラグイン、テーマの版を問い合わせます。
api.wordpress.orgだけを許可すれば、更新に関するすべての通信が完了するとは限りません。更新ファイルの取得先や、各プラグインが使うサービスは別のホストになる場合があります。実際に必要な機能ごとに接続先を確認し、そのホストだけを追加します。
*.wordpress.orgのようなワイルドカードも使えます。しかし、一つのホスト名を指定する場合より許可範囲が広がります。必要な接続先を個別に管理できるなら、具体的なホスト名を優先します。
許可はURLではなくホスト名で判断される
WP_ACCESSIBLE_HOSTSは、URL全体の一覧ではありません。要求先URLからホスト名を取り出して照合するため、同じホストの特定のパスだけを許可する設定には使えません。
たとえば、ある外部サービスの取得用URLだけを許可し、同じホストの送信用URLを止めるという分け方はできません。目的ごとに通信を分ける必要があるなら、接続先ホストを分けられるか、サーバー側のプロキシや通信制御で条件を設けられるかを確認します。
ホスト名を許可したことと、そのサービスへ送る内容を承認したことも同じではありません。送信先、送信する項目、送信時刻、失敗時の動作を、機能ごとに確認します。顧客情報や注文情報を扱う機能では、ホスト名だけを記録しても引継ぎ資料として足りません。
WordPress HTTP API以外の通信は止まらない
wp_remote_get()、wp_remote_post()、wp_remote_request()は、WordPressのHTTP関数を通じてWP_Httpを使います。二つの定数は、この経路にある要求を制御します。
プラグインやテーマがPHPの別の通信機能を直接使う場合、その要求までこの定数で止めることはできません。したがって、WP_HTTP_BLOCK_EXTERNALを設定した状態を、サーバーから外部への通信をすべて遮断した状態とは扱えません。
目的が、サーバーから許可先以外へ一切接続させないことであれば、WordPressの設定だけでは不足します。サーバーのファイアウォールやプロキシを管理する人と、送信元、送信先、プロトコル、記録方法を決めます。WordPressの定数は、WordPress HTTP APIを使う機能の制御として位置付けます。
設定前に機能と接続先の対応を記録する
接続先一覧は、ドメイン名だけを並べず、何のために使うかを一緒に記録します。
| 機能 | 確認するもの | 設定後の確認 |
|---|---|---|
| WordPress本体の更新確認 | 問い合わせ先ホスト、実行時刻 | 更新情報を取得できるか |
| プラグインとテーマ | 外部サービス、更新確認、ファイル取得先 | 管理画面と定期処理の両方が動くか |
| サイト固有の連携 | 送信先、送信項目、失敗時の扱い | 一件を実行し、結果とエラーを確認できるか |
管理画面でボタンを押す操作だけでなく、予約された処理も確認します。昼間の確認では動いていても、夜間の定期処理が別のホストへ接続する場合があります。作業を委託するなら、プラグイン名の一覧だけでなく、実際の接続先と停止時の連絡先を受け取ります。
確認用の環境で遮断と許可を同時に試す
まず、現在のwp-config.phpを安全な場所へ保存し、同じ定数が定義済みでないか調べます。接続先一覧を作ったら、WordPress本体を読み込む行より前へ二つの定数を追加します。
設定後は、許可した機能が動くことだけでなく、一覧にない外部ホストへの要求がWP_Errorになることも確認します。更新確認、プラグインの主要操作、定期処理を一つずつ実行し、失敗を確認できる記録を残します。
公開サイトへ反映するときは、設定値、許可理由、確認した機能、確認日、変更担当、元へ戻す担当を残します。接続先が変わるサービスを使う場合は、変更を誰が確認し、いつ許可一覧を見直すかも決めます。
最初の一手は、外部通信を一括で止めることではありません。現在動いている機能を一つ選び、接続先ホスト、送信内容、実行時刻、失敗時の影響を書き出してください。
関連記事

