2026年5月20日

wp-config.php とは？場所・パーミッション・安全な設定｜認証キー、DISALLOW_FILE_EDIT、.bak の置き方

セキュリティ

wp-config.php を安全にするための作業は、大きく「ファイルを読まれにくくする（設置場所・パーミッション・Webサーバーでの拒否）」と「中に書く設定で被害を小さくする（認証用キー、DISALLOW_FILE_EDIT、FORCE_SSL_ADMIN など）」の2つです。この記事では、それぞれの設定が何を防ぐのか、どこでつまずきやすいのか、設定後にどう確認するのかを順に説明します（2026年10月現在のWordPressを前提にしています）。

作業の前に、wp-config.php のコピーをサーバー外に保存しておいてください。記述を1文字間違えるだけでサイト全体が表示されなくなるため、すぐ元に戻せる状態にしておくことが大切です。

wp-config.phpに何が書かれているか

wp-config.php には、データベース名・ユーザー名・パスワード・ホスト名、ログイン状態を守るための認証用キーとソルト、テーブル接頭辞などが書かれています。このファイルが第三者に読まれると、データベースに直接接続されたり、ログインCookieを偽造されたりするおそれがあります。

通常、PHPファイルはWebサーバーで実行されるため、ブラウザで wp-config.php を開いても中身は表示されません。問題になるのは次のような場面です。

サーバーの設定ミスや更新作業中にPHPが動かず、ソースがそのまま返される
エディタが作ったバックアップ（wp-config.php.bak、wp-config.php~、wp-config.php.save など）が残っていて、PHPとして実行されずテキストとしてダウンロードされる
同じサーバー上の別のユーザーやアプリから、ファイルとして読まれる

以下の対策は、これらの経路を一つずつ塞ぐものです。

設置場所を1つ上の階層に移す

WordPressは、wp-config.php がWordPressのインストールディレクトリ（wp-settings.php がある場所）に見つからない場合、1つ上のディレクトリを探します。ただし、その上の階層に別の wp-settings.php がある場合（別のWordPressがある場合）は読み込みません。

# 例: ドキュメントルートが /var/www/example.com/public で、WordPressがその直下にある場合
cd /var/www/example.com
cp public/wp-config.php ./wp-config.php.backup
mv public/wp-config.php ./wp-config.php

この移動に意味があるのは、1つ上の階層がドキュメントルートの外にある場合です。上の例なら /var/www/example.com/ はURLでアクセスできないため、PHPが動かない事故が起きても wp-config.php は配信されません。逆に、レンタルサーバーで public_html/wordpress/ のようにサブディレクトリに設置している場合、1つ上の public_html/ はまだ公開領域なので、移しても効果はほとんどありません。

移動後はサイトと管理画面が正常に表示されるかを確認します。サーバーによっては open_basedir の制限でドキュメントルートの外を読めないことがあり、その場合はデータベース接続エラーになります。

ファイルのパーミッションと所有者

パーミッションは「PHPを実行するユーザーが読めて、それ以外の一般ユーザーは読めない」状態にします。どの値が適切かは、PHPがどのユーザーで動いているかによって変わります。

# PHP-FPMがサイト専用ユーザー（例: example）で動いている場合
sudo chown example:example /var/www/example.com/wp-config.php
sudo chmod 600 /var/www/example.com/wp-config.php

# ファイルの所有者は作業用ユーザー、PHPはwww-dataグループで読む場合
sudo chown deploy:www-data /var/www/example.com/wp-config.php
sudo chmod 640 /var/www/example.com/wp-config.php

# 確認
stat -c '%a %U:%G %n' /var/www/example.com/wp-config.php

600 にしてサイトが真っ白になったり、データベース接続エラーが出たりする場合は、PHPの実行ユーザーとファイルの所有者が一致していません。ps aux | grep php-fpm で実行ユーザーを確認し、所有者かグループを合わせます。一般的なレンタルサーバーでは、サーバー会社が推奨するパーミッション（400、440、600 など）に従ってください。

書き込み権限を外すと、キャッシュ系プラグインなどが wp-config.php に定数を自動で書き込む処理は失敗します。その場合は、プラグインが案内する1行を手作業で追記すれば足ります。

Webサーバーで直接アクセスを拒否する

ドキュメントルートの外に移せない場合や、念のための二重の対策として、Webサーバー側で wp-config.php へのアクセスを拒否します。

Apache 2.4 では .htaccess に次のように書きます。WordPressが自動で書き換える # BEGIN WordPress 〜 # END WordPress の外側に置いてください。内側に書くと、パーマリンク設定の保存時に消えます。

<Files wp-config.php>
    Require all denied
</Files>

Nginx では、server ブロックの PHP 処理より前に置きます。バックアップファイルもまとめて拒否しておくと安心です。

location ~* /wp-config\.php {
    deny all;
}
location ~* \.(bak|old|orig|save|swp)$|~$ {
    deny all;
}

設定後、外部からアクセスして拒否されるかを確認します。

curl -I https://example.com/wp-config.php
# 403 Forbidden が返れば拒否できている

あわせて、ls -la でドキュメントルートにバックアップファイルが残っていないかも確認し、不要なものは削除します。

認証用キーとソルトを固有の値にする

AUTH_KEY から NONCE_SALT までの8つの定数は、ログインCookieやnonceの生成に使われます。初期値の put your unique phrase here のままになっていたり、他のサイトからコピーした値を使っていたりする場合は、新しい値に置き換えます。

WordPress公式の生成ページ（https://api.wordpress.org/secret-key/1.1/salt/）にアクセスすると、8行分のランダムな値が表示されるので、wp-config.php の該当箇所と差し替えます。WP-CLIが使える環境なら、次のコマンドで同じことができます。

wp config shuffle-salts

キーを変更すると、ログイン中のすべてのユーザーがログアウトされます。不正ログインが疑われるときには、既存のログイン状態を無効にする手段としても使えます。キーの値は外部に公開したり、Gitリポジトリにコミットしたりしないでください。

被害を広げないためのセキュリティ定数

wp-config.php の「編集が必要なのはここまでです」というコメントより上に、次の定数を追加します。

// 管理画面のテーマ・プラグインのファイルエディターを無効化
define( 'DISALLOW_FILE_EDIT', true );

// 管理画面からのプラグイン・テーマのインストールと更新も禁止する場合
// define( 'DISALLOW_FILE_MODS', true );

// 管理画面とログインをHTTPSに限定
define( 'FORCE_SSL_ADMIN', true );

// 本番環境ではエラーを画面に出さない
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

DISALLOW_FILE_EDIT は、管理画面の「テーマファイルエディター」「プラグインファイルエディター」を無効にします。管理者アカウントが乗っ取られた場合に、画面からPHPコードを書き換えられるのを防ぎます。普段の運用にはほとんど影響がないため、まず入れておきたい設定です。

DISALLOW_FILE_MODS は、さらに管理画面からのプラグイン・テーマの追加、更新、削除と、コアを含む自動更新も止めます。更新をWP-CLIやデプロイの仕組みで管理している環境向けです。管理画面からの更新に頼っているサイトで有効にすると、セキュリティ更新が適用されなくなるので注意してください。

FORCE_SSL_ADMIN は、ログイン画面と管理画面へのアクセスをHTTPSに限定します。ロードバランサーやCDNでHTTPSを終端し、WordPressへはHTTPで届く構成では、WordPressがHTTPSだと認識できず、リダイレクトが繰り返されることがあります。その場合は、プロキシが付けるヘッダーを見て判定する記述を追加します。

// 信頼できるプロキシの背後にある場合のみ
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

デバッグログを残したい場合は、define( 'WP_DEBUG_LOG', '/var/www/example.com/logs/debug.log' ); のようにドキュメントルートの外のパスを指定できます。true にすると wp-content/debug.log に書かれ、URLで読めてしまうことがあるためです。

データベース接続情報の扱い

DB_USER には、そのサイト専用で、対象のデータベースにだけ権限を持つMySQLユーザーを使います。root や、複数サイトで共有しているユーザーを指定していると、1つのサイトから漏れたときに被害がほかのサイトに広がります。

テーブル接頭辞（$table_prefix）を wp_ 以外にする設定もよく紹介されますが、効果は限定的です。既存サイトで変更するとデータベース内の参照も書き換える必要があるため、新規インストール時に決める項目と考えてください。

設定後の確認

最後に、次の点を確認します。

サイトの表示、管理画面へのログイン、投稿の保存ができる
curl -I https://example.com/wp-config.php が403を返す
管理画面の「外観」「プラグイン」メニューにファイルエディターが表示されない
stat で確認したパーミッションと所有者が意図どおり
ドキュメントルートに wp-config.php のバックアップファイルが残っていない

表示が崩れた場合は、最初に保存したコピーに戻し、追加した記述を1つずつ確認します。

まとめ

wp-config.php は、1つ上の階層がドキュメントルート外なら移動しておくと、PHPが動かない事故でも配信されない
パーミッションはPHPの実行ユーザーが読める最小限（600 や 640 など）にする
Apache・Nginxで wp-config.php とバックアップファイルへのアクセスを拒否し、curl -I で403を確認する
認証用キーとソルトは固有の値にし、漏えいが疑われるときは wp config shuffle-salts で入れ替える
DISALLOW_FILE_EDIT と FORCE_SSL_ADMIN を入れ、更新の運用に合わせて DISALLOW_FILE_MODS を検討する