ラピットくん 
保守している WordPress で、PHP の設定を一つ切ろうとしました。切れませんでした。
で、どうしたか。サーバーは替えずに、切れなかったことを報告書に書きました。
allow_url_fopen は一例です。保守をしていると、「やったほうがいい対策なのに、その環境ではできない」が必ず出てきます。そのとき何を見て、どう決めて、どう残したかを書いておきます。
そもそも allow_url_fopen とは
PHP の設定の一つです。PHP のマニュアルにあるとおり、On にすると、プログラムがインターネット上のファイルを、サーバー内のファイルと同じ手順で読めるようになります。
file_get_contents('https://example.com/data.txt');便利な反面、不正なプログラムを置かれたときに、外から追加の部品を取り込む入口になります。なので、使わないなら Off、がよく言われる対策です。
保守では、使っていない入口はなるべく閉じておきたい。なので、切ることにしました。
書き換えても、On のままだった
Xserver には、ドメインごとの php.ini があります。そこで allow_url_fopen = Off に書き換えました。
確認用の小さな PHP をサイトに置いて、実際の値を出してみました。
On のままでした。
.user.ini（フォルダごとに PHP の設定を変えるファイル）でも変わりません。allow_url_fopen は、サーバー全体の設定でしか決められない種類の項目です。
じゃあパネルから、とサーバーパネルの「php.ini設定」を開くと、この項目だけ「ON ※」と固定で表示されていて、選べませんでした。
理由は Xserver のマニュアルに書いてあります。高速化の機能「Xアクセラレータ Ver.2」を使っていると、allow_url_fopen を含む一部の項目は、サーバーの初期値（On）が使われます。
高速化を止めれば変えられるかもしれません。ただ、表示が遅くなると、見に来た人が離れます。表示を遅くしてまで切る設定ではない、と判断しました。
ほかのサーバーなら、どうだったか
ここで「じゃあサーバーを替えれば」と言いたくなります。調べました。
| サーバー | php.ini の変え方 | allow_url_fopen |
|---|---|---|
| Xserver | パネル「php.ini設定」 | Xアクセラレータ Ver.2 では初期値（On）に固定 |
| さくらのレンタルサーバ | パネル「スクリプト設定 > php.ini設定」 | 編集はできる。ただし一部の項目は設定できない場合があるとされている |
| ConoHa WING | 「サイト設定 > 応用設定 > PHP設定 > php.ini編集」 | 編集はできる。項目ごとの可否の記載はなし |
| VPS（自分でサーバーを持つ） | 設定ファイルを直接 | 確実に変えられる |
さくらと ConoHa は、パネルから php.ini を書き換えられます。ただ、allow_url_fopen が実際に Off になるかは、公式の情報だけでは確かめきれませんでした。Xserver でも、書き換え自体はできたけれど効いていなかったので。乗り換えるなら、書いたあとに実際の値を出して確かめる、までがセットです。
VPS なら確実です。その代わり、サーバーそのものの更新も見張りも、自分の仕事になります。
要するに、Xserver だから、という話ではありません。どのサーバーにも、仕様で変えられない設定や、変えると別のところに響く設定があります。今回はそれが、たまたま allow_url_fopen だった。
それでも、乗り換えなかった
理由は4つです。
1. いま多い改ざんは、サーバーで外を読みに行かない
WordPress の改ざんでよく見るのは、サイトに小さなスクリプトを埋めて、見に来た人のブラウザに外の部品を読み込ませる型です。偽の認証画面を出して、パソコンでコマンドを実行させる「ClickFix」もこの仲間です。外を読みに行くのはサーバーではないので、allow_url_fopen を Off にしても止まりません。
2. もっと危ない設定は、最初から Off
兄弟分の allow_url_include（外のファイルを、プログラムとして実行する）は、Xserver の初期値で Off です。外から取り込んだものをそのまま実行される道は、ふさがっています。
3. 切っても、別の道で取りに来る
外から部品を取ってくる不正なプログラムは、allow_url_fopen が Off なら curl に切り替えて取りに来るものが多い、とマルウェアの分析でも書かれています。これ一つで止まる攻撃は、多くありません。
4. Xserver には、もっと効く守りが無料である
- WAF設定：SQL を使った攻撃や、スクリプトを埋め込む攻撃を、サーバーの手前で止める
- WordPressセキュリティ設定：管理画面・XML-RPC・REST API への、国外からのアクセスを止める（初期値で ON）
- 2026年6月からは、管理画面に入れる IP アドレスを絞る機能も
WordPress の被害の入口は、だいたいログインかプラグインの穴か、更新の放置です。allow_url_fopen は、入られたあとの一手間を増やす設定です。乗り換えの手間とリスクを払うなら、ログインと更新を固めるほうが先。
▼関連記事
レンタルサーバー代が3年で1.5倍に。AI需要で上がり続けるインフラ費に、いま何ができるか
切れなかったことを、報告書に書いた
「できなかった対策」は、黙っておくこともできます。誰も気づかないかもしれない。
でも半年後、別の会社が点検に入って「allow_url_fopen が On ですね」と言ったら、どうなるか。「なぜ切っていなかったのか」に、誰も答えられなくなります。
なので、お客さんに出す保守の報告書の「残存リスクと今後の推奨対応」に、1項目として書きました。中身はこの4つです。
- 状態：On のまま。リスクの大きさは「小」
- できない理由：サーバーの仕様。高速化を止めれば変えられる可能性はあるが、表示が遅くなるので止めない
- 小さいと判断した理由：上の1〜4に加えて、改ざんの検知と、消せない控えで、置かれてもすぐ気づけて戻せる
- 今後：サーバーの仕様が変われば切る。より守りを固めるなら、サイトの手前に攻撃を止める仕組みを置く
こう書いておけば、On のままなのは「やり忘れ」ではなく「判断」として残ります。あとから来た人も、続きから考えられる。
入らなかった対策も、説明できれば「判断」になる
セキュリティの記事には、「これをやりましょう」のリストがたくさんあります。で、実際の現場では全部は入りません。今回みたいにサーバーの仕様で入らないこともあるし、入れるとサイトが遅くなることもある。
入らなかったときに、
- 本当に効くのか（いま多い手口に関係するか）を確かめる
- 代わりに何で守っているかを並べる
- それを書いて、お客さんに渡す
ここまでやれば、入らなかった対策も、ちゃんと説明できるものになります。
参考
- ファイルシステム関数の実行時設定（allow_url_fopen）（PHP マニュアル）
- XアクセラレータVer.2利用時に無効となるphp.ini設定について（Xserver）
- php.ini設定で設定可能な項目（Xserver）
- WAF設定（Xserver）
- WordPressセキュリティ設定（Xserver）
- WordPress管理画面へのアクセス元を限定できる「IPアドレス制限」機能追加のお知らせ（Xserver・2026年6月18日）
- php.iniの設定内容を変更したい（さくらのレンタルサーバ）
- PHPの設定をする（ConoHa WING）
- An Analysis of WordPress Malware（Imunify360）
- ClickFix（Wikipedia）
2026年10月17日時点の各社の情報によります。
▼関連記事
韓国の銀行を狙った攻撃は、Claude Codeの作業ノートから手口がバレました
WordPress の保守、引き継ぎで困っていませんか
誰がどの設定をしたのか分からない。どこまで対策できているのか、説明できる人がいない。そういうサイトの点検と保守も引き受けています。
