• HOME
  • WordPressのwp-config.phpを安全に設定する方法（秘密鍵・デバッグ・権限・アクセス拒否）

2026年5月31日

  • シェア
  • ツイート

    • 2026年5月31日

    WordPressのwp-config.phpを安全に設定する方法（秘密鍵・デバッグ・権限・アクセス拒否）

    wp-config.php には、データベースのユーザー名とパスワード、ログインの Cookie を守る秘密鍵が書かれています。このファイルの中身が漏れると、データベースへの侵入やログイン状態の偽造につながります。この記事では、wp-config.php で見直す設定と、ファイル自体を守る方法を順に説明します。

    手順は、2026年11月時点の WordPress 7.1、WP-CLI 2.12、Apache 2.4 で確かめています。作業の前に wp-config.php のコピーを、ドキュメントルートの外に取っておいてください。

    秘密鍵（認証用キーとソルト）を更新する

    wp-config.php には次の8つの定数があり、ログイン Cookie の暗号化と検証に使われます。

    <?php
define( 'AUTH_KEY',         'ここに一意の文字列' );
define( 'SECURE_AUTH_KEY',  'ここに一意の文字列' );
define( 'LOGGED_IN_KEY',    'ここに一意の文字列' );
define( 'NONCE_KEY',        'ここに一意の文字列' );
define( 'AUTH_SALT',        'ここに一意の文字列' );
define( 'SECURE_AUTH_SALT', 'ここに一意の文字列' );
define( 'LOGGED_IN_SALT',   'ここに一意の文字列' );
define( 'NONCE_SALT',       'ここに一意の文字列' );

    値が初期値（put your unique phrase here）のままだったり、ほかのサイトと同じだったりする場合は、新しい値に置き換えます。方法は2つあります。

    • WordPress.org の生成ページ https://api.wordpress.org/secret-key/1.1/salt/ を開き、表示された8行で既存の8行を置き換えます。開くたびに新しい値が出ます。
    • WP-CLI が使える場合は、次のコマンドで8つの値をまとめて新しくできます。
    cd /var/www/html
wp config shuffle-salts

    秘密鍵を変えると、ログイン中のすべてのユーザーの Cookie が無効になり、全員がログアウトします。不正アクセスが疑われるとき（パスワードの漏えい、乗っ取られたアカウントがあるなど）は、パスワードの変更とあわせて秘密鍵を更新します。利用者がログインしているサイトでは、影響の少ない時間帯に行います。

    本番ではエラーを画面に出さない

    本番でエラーが画面に表示されると、サーバー内のファイルのパスやプラグインの構成が外部に見えてしまいます。本番では次のように設定します。

    <?php
// 本番: エラーを画面に出さない
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

    調査のために一時的にログを取る場合は、画面には出さずにファイルに記録します。WP_DEBUG_LOG に true を指定すると wp-content/debug.log に書かれますが、この場所は URL で開けてしまいます。ファイルのパスを指定して、ドキュメントルートの外に書き出します。

    <?php
// 調査中だけ: ログをドキュメントルートの外に記録する
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' ); // Webサーバーが書き込めるディレクトリにする

    調査が終わったら WP_DEBUG を false に戻します。詳しくは 本番環境でWP_DEBUGを無効にする方法 を参照してください。

    セキュリティに関わる定数

    管理画面からのファイル編集を禁止する（DISALLOW_FILE_EDIT）

    <?php
define( 'DISALLOW_FILE_EDIT', true );

    「外観」→「テーマファイルエディター」と「プラグイン」→「プラグインファイルエディター」が使えなくなります。管理者アカウントが乗っ取られたときに、管理画面から PHP のコードを書き換えられるのを防ぎます。試したところ、設定後も管理者はプラグインの更新（update_plugins 権限）はできました。

    ただし、ファイルをアップロードする攻撃までは防げません。WordPress の公式文書でも「一部の攻撃を止められる」程度の対策とされています。

    プラグイン・テーマの追加と更新を禁止する（DISALLOW_FILE_MODS）

    <?php
define( 'DISALLOW_FILE_MODS', true );

    管理画面からのプラグイン・テーマのインストール、更新、削除ができなくなります。注意が必要なのは、WordPress 本体の自動更新（セキュリティ更新を含む）も止まることです。試した環境でも、この定数を入れると自動更新の仕組みが無効と判定されました。

    使う場合は、更新を自分で行う仕組みを用意します。たとえば WP-CLI を cron から定期的に実行します。

    cd /var/www/html
wp core update --minor   # 本体のマイナー（セキュリティ）更新だけを適用する
wp plugin update --all

    更新を Git などのデプロイで管理していないサイトでは、DISALLOW_FILE_MODS ではなく DISALLOW_FILE_EDIT だけを使うほうが安全です。

    管理画面とログインをHTTPSに限る（FORCE_SSL_ADMIN）

    <?php
define( 'FORCE_SSL_ADMIN', true );

    管理画面とログイン画面を HTTP で開いたときに HTTPS へ転送し、ログインの Cookie を HTTPS の通信でだけ送るようにします。サイトが HTTPS で開けることを確かめてから設定します。ロードバランサーや CDN の後ろにあるサーバーでは、WordPress が HTTPS で受けたことを判別できず、転送が繰り返される場合があります。その場合はサーバー側の設定もあわせて見直します。

    テーブル接頭辞（$table_prefix）

    $table_prefix の初期値は wp_ です。公式文書は、wp_ を前提にした SQL インジェクション攻撃の一部を防げる、としています。ただし効果は限られ、変えれば安全になるものではありません。新しくインストールするときに変えるのが簡単で、既存のサイトで変える場合はテーブル名と、options・usermeta テーブルの中の接頭辞付きの値も書き換える必要があります。

    Webから直接読まれないようにする

    Apacheでアクセスを拒否する

    wp-config.php は PHP として実行されるので、通常は URL で開いても中身は表示されません（試したところ、空のページが返りました）。ただ、サーバーの設定ミスなどで PHP が動かなくなると、中身がそのまま表示されるおそれがあります。念のため、Web からのアクセスを拒否しておきます。

    Apache 2.4 では、WordPress のディレクトリの .htaccess の先頭（# BEGIN WordPress より前）に次のように書きます。

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

    試したところ、設定後は /wp-config.php へのアクセスが 403 になり、サイトはふだんどおり表示されました。Order allow,deny と Deny from all は Apache 2.2 の書き方です。Apache 2.4 では Require all denied を使います。

    Nginx の場合は、server ブロックに次のように書きます。

    location = /wp-config.php {
    deny all;
}

    バックアップのコピーを残さない

    wp-config.php.bak や wp-config.php.old、エディターが作る wp-config.php~ のようなコピーは、拡張子が .php ではないので PHP として実行されず、テキストとして表示されます。試した環境でも、wp-config.php.bak を置くとパスワードを含む中身がそのまま読めました。ドキュメントルートの中に wp-config.php のコピーを置かないでください。

    # ドキュメントルートに残っているコピーを探す
find /var/www/html -maxdepth 1 -name 'wp-config*' ! -name 'wp-config.php' ! -name 'wp-config-sample.php'

    パーミッションと所有者を設定する

    WordPress の公式文書は、wp-config.php を「自分（とWebサーバー）だけが読める」ようにし、一般には 400 か 440 にするよう勧めています。どちらにするかは、ファイルの所有者と、PHP を実行するユーザーの関係で決まります。

    状況 所有者:グループ パーミッション
    PHP がファイルの所有者と同じユーザーで動く（多くのレンタルサーバー） 自分のユーザー 400 または 440
    PHP が Web サーバーのユーザー（www-data など）で動き、ファイルは別のユーザーが所有 自分のユーザー:www-data 440

    試したところ、所有者を root、グループを www-data にした場合、440 ではサイトが表示され、400 では PHP が wp-config.php を読めずにエラー（HTTP 500）になりました。

    # 例: 所有者を deploy ユーザー、グループを www-data にして 440 にする
sudo chown deploy:www-data /var/www/html/wp-config.php
sudo chmod 440 /var/www/html/wp-config.php
ls -l /var/www/html/wp-config.php

    440 にすると WordPress やプラグインは wp-config.php を書き換えられません。キャッシュ系のプラグインなど、設定時に wp-config.php へ追記するものを入れるときは、一時的に書き込みを許可するか、自分で追記します。

    ほかのファイルとディレクトリは、ディレクトリ 755、ファイル 644 が基本です。全体の考え方は WordPressのファイルパーミッションを正しく設定する方法 にまとめています。

    wp-config.phpを1階層上に移す

    WordPress は、wp-config.php が WordPress のディレクトリにない場合、1つ上のディレクトリを探します。ドキュメントルートが /var/www/html なら、/var/www/wp-config.php に置いても動きます。

    mv /var/www/html/wp-config.php /var/www/wp-config.php

    試したところ、移動後もサイトは表示され、/wp-config.php の URL は 404 になりました。ただし、次の点に注意してください。

    • 1つ上のディレクトリに wp-settings.php がある場合（そこにも WordPress が入っている場合）は読み込まれません。
    • WordPress をサブディレクトリ（例: /var/www/html/blog）に入れている場合、1つ上は /var/www/html でドキュメントルートの中なので、Web から守る効果はありません。
    • 公式文書は、移動の効果は小さいという意見もあると書いています。パーミッションとアクセス拒否の設定を先に行ってください。

    確認のチェックリスト

    • 秘密鍵が初期値のままになっていない
    • 本番で WP_DEBUG が false、WP_DEBUG_DISPLAY が false
    • wp-content/debug.log が残っていない（残っていれば削除する）
    • DISALLOW_FILE_EDIT が true
    • /wp-config.php への直接のアクセスが拒否される
    • ドキュメントルートに wp-config.php のコピーがない
    • wp-config.php が 400 か 440 で、サイトが正常に表示される

    関連記事

    Views: 185

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲