なぜ「プラグインのコード編集」を止めることがセキュリティになるのか
WordPress には、管理画面から直接プラグインの PHP ファイルを編集できる機能があります。
プラグイン → プラグインファイルエディター
から、xxx-plugin/xxx.php をその場で書き換えられますよね。
一見「便利そう」に見えますが、セキュリティの観点ではかなり危険です。
理由はシンプルで、「管理画面に侵入された瞬間、そこから“自由にサーバー上のコードを書き換えられる”」からです。
攻撃者が管理者アカウントを奪った場合、
プラグインエディタを開く
任意の PHP コード（バックドア）を書き込む
保存する
これだけで、サーバーをほぼ好き放題にできます。
だから、「そもそも管理画面からコードを編集できないようにしておく」のは、とても強力な防御になります。
「プラグインのコード編集を無効化する」とは何をするのか
管理画面から「編集」という入口を消してしまう
やりたいことはシンプルです。
プラグイン → プラグインファイルエディター
外観 → テーマファイルエディター
この2つの「エディター機能」を、丸ごと使えなくしてしまう、ということです。
具体的には、
メニューから「プラグインファイルエディター」「テーマファイルエディター」が消える
URLを直接叩いても、エディター画面にアクセスできない
という状態を作ります。
これによって、
管理者であっても、管理画面から直接 PHP コードをいじれない
＝「侵入されたときの被害の広がり方」をかなり抑えられる
という効果が生まれます。
どうやって無効化するのか（考え方とイメージ）
wp-config.php に「編集禁止」の設定を書く
WordPress には、
「管理画面からファイル編集を禁止する」ための定数が用意されています。
イメージとしては、wp-config.php に次のような一行を追加します。
define( 'DISALLOW_FILE_EDIT', true );
これを有効にすると、
プラグインファイルエディター
テーマファイルエディター
の両方が、管理画面から使えなくなります。
プログラミングの感覚で言えば、
「本番環境では管理画面からコードをいじる機能を殺すフラグ」
をオンにするイメージです。
なぜ wp-config.php なのか
wp-config.php は、WordPress の「設定の中枢」です。
ここに書かれた定数は、WordPress のかなり早い段階で読み込まれます。
そのため、
管理画面の権限設定よりも前に
プラグインやテーマの読み込みよりも前に
「ファイル編集はダメ」というルールを適用できます。
つまり、「誰がログインしていても、管理画面からコード編集はできない」という強い制限になります。
例題：攻撃されたときの“差”をイメージしてみる
無効化していない場合
攻撃者が何らかの方法で管理者アカウントを奪ったとします。
そのときにできることは、例えばこんな感じです。
プラグインファイルエディターを開く
任意のプラグインのメインファイルに、悪意あるコードを追記
保存する
これで、
管理画面に入れなくなっても
プラグインのコードに埋め込んだバックドアから再侵入
といったことが可能になります。
つまり、「一度入られたら、根を張られやすい」状態です。
無効化している場合
同じように管理者アカウントを奪われても、
プラグインファイルエディターがそもそも存在しない
テーマファイルエディターも使えない
という状態なので、
管理画面から PHP コードを直接書き換える
というルートは封じられています。
もちろん、他の脆弱性があれば別ルートもあり得ますが、
「管理画面からのコード改ざん」という強力な武器を1つ奪えるのは大きいです。
「便利さ」と「安全さ」のトレードオフをどう考えるか
正直、管理画面からコードをいじるべきではない
開発者目線で言うと、
本番環境のコードをブラウザから直接編集するのは、かなり危険な行為です。
タイプミス1つでサイトが真っ白になる
変更履歴が残りにくい（Git で管理できない）
ロールバックが難しい
など、セキュリティ以前に「運用として危うい」ポイントがたくさんあります。
理想的には、
ローカルや開発環境でコードを編集
Git などでバージョン管理
テストしてから本番に反映
という流れにした方が、
品質的にもセキュリティ的にも圧倒的に健全です。
「どうしても編集したいとき」は別ルートで
もしどうしてもコードを触りたいなら、
FTP / SFTP でサーバーに接続して編集する
SSH で入ってエディタ（vim, nano など）で編集する
といった「一段階ハードルの高い方法」を使う方が安全です。
管理画面からワンクリックでコードをいじれる状態は、
「自分にとっても攻撃者にとっても便利すぎる」のが問題です。
プログラミングの感覚で捉える「プラグインコード編集の無効化」
これは「本番環境の管理コンソールから危険な機能を封じる」設計
Webアプリケーションの世界では、
本番環境の管理画面から
SQL を直接叩けるコンソール
任意コード実行ができるコンソール
などを開放しておくのは、
ほぼ自殺行為です。
WordPress のプラグイン／テーマエディターは、
それにかなり近い「危険な管理機能」です。
DISALLOW_FILE_EDIT を true にするのは、
「本番の管理画面から任意コード実行の入口を閉じる」
という、非常にまっとうな設計判断です。
「侵入される前提」で“被害の広がり方”を制限する
セキュリティ設計で大事なのは、
絶対に侵入されないようにする
ではなく
侵入されても被害を最小限にする
という発想です。
プラグインのコード編集を無効化するのは、
もし管理者アカウントを奪われても
そこからサーバー全体を好き放題いじられないようにする
という、「被害の広がり方を制限する」ための一手です。
まとめ：コード編集無効化は“地味だけど効く”セキュリティ設定
「プラグインのコード編集を無効化」というのは、
管理画面から任意のPHPコードを書き込めなくする
＝管理画面が乗っ取られたときの被害を大きく減らす
という、とても重要なセキュリティ強化です。
やること自体はシンプルで、
wp-config.php にDISALLOW_FILE_EDIT を true で定義する
これだけです。
その代わり、
本番環境のコードは管理画面からいじらない
編集が必要なら、FTP やGitベースの運用に切り替える
という「エンジニアとして健全な運用」に一歩近づくことにもなります。
今日、wp-config.php を一度開いて、
この一行を入れるかどうか、真剣に考えてみてください。
それは、あなたが「ただの WordPress ユーザー」から
「自分のサイトのセキュリティ設計を意識しているエンジニア」に変わる、小さな一歩になります。
