.htaccessでディレクトリをパスワード保護する方法（Basic認証・WordPress対応）

.htaccess に Basic 認証を設定すると、指定したディレクトリを開いたときにブラウザが ID とパスワードの入力を求めるようになります。公開前のテストサイト、関係者だけに渡すファイル置き場、WordPress の管理画面（/wp-admin/）などを、WordPress のログインとは別にもう一段守る方法です。

この記事では Apache 2.4 での書き方を中心に、WordPress で使うときに外してはいけないファイル、Nginx での書き方、うまく動かないときの確認点を説明します。

この方法が使える環境

• Web サーバーが Apache（または .htaccess を読む LiteSpeed）であること。Nginx は .htaccess を読まないため、サーバーの設定ファイルに書きます（後述）。
• .htaccess で認証の設定を書くには、サーバー側で AllowOverride AuthConfig（または All）が許可されている必要があります。許可されていない場合は 500 エラーになります。多くのレンタルサーバーでは許可されています。
• SSH で htpasswd コマンドを使えるか、レンタルサーバーの管理パネルに「アクセス制限」「Basic 認証」などの機能があること。管理パネルに機能がある場合は、そちらを使うほうが手軽で、パスワードファイルの置き場所もサーバー会社の推奨どおりになります。
• サイトが HTTPS で表示されること。Basic 認証の ID とパスワードは暗号化されずに送られるため、HTTP のままでは通信の途中で読み取られるおそれがあります。

手順1: パスワードファイル（.htpasswd）を作る

SSH でサーバーに入り、Apache に付属する htpasswd コマンドでパスワードファイルを作ります。

# 新しくファイルを作ってユーザー wpuser を登録する（-c は新規作成。既存のファイルに使うと上書きされる）
# -B はパスワードを bcrypt 形式で保存する指定
htpasswd -c -B /home/username/.htpasswd wpuser

# 2人目以降を追加するときは -c を付けない
htpasswd -B /home/username/.htpasswd another-user

# 登録したユーザーを削除する
htpasswd -D /home/username/.htpasswd another-user

コマンドを実行するとパスワードを2回入力するよう求められます。作られたファイルには wpuser:$2y$05$... のように、ユーザー名とハッシュ化されたパスワードが1行ずつ並びます。

パスワードファイルは、Web から直接開けない場所（ドキュメントルートの外）に置きます。上の例の /home/username/ は、自分のアカウントのホームディレクトリなど、実際の環境に合わせて置き換えてください。ドキュメントルートの中にしか置けない場合でも、Apache の標準設定では .ht で始まるファイルは外から読めないようになっていますが、外に置けるならそのほうが安全です。

.htaccess の AuthUserFile には、このファイルのフルパス（/ から始まるパス）を書きます。フルパスがわからない場合は、パスワードファイルを置いたディレクトリで pwd を実行すると確認できます。

手順2: 保護したいディレクトリに .htaccess を置く

保護したいディレクトリ（例: /members/）に .htaccess を作り、次のように書きます。このディレクトリとその下にあるファイルすべてに認証がかかります。

# /members/.htaccess
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user

• AuthName は、認証の範囲（realm）を区別するための名前です。同じ名前の範囲では、一度入力した ID とパスワードがそのまま使われます。日本語は文字化けすることがあるため、英数字で書きます。
• Require valid-user は、パスワードファイルに登録したユーザーなら誰でも通す指定です。特定のユーザーだけ通す場合は Require user wpuser のように書きます。

WordPress の管理画面（wp-admin）を保護する場合

/wp-admin/ に Basic 認証をかけるときは、wp-admin フォルダーの中に .htaccess を作ります（WordPress 本体には含まれていないファイルです。すでにある場合は中身を確かめてから追記します）。

# wp-admin/.htaccess
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user

# サイトの表側からも呼ばれるファイルは認証の対象から外す
<Files "admin-ajax.php">
    Require all granted
</Files>

admin-ajax.php は、問い合わせフォームの送信、絞り込み検索、WooCommerce のカート更新など、ログインしていない訪問者が使う機能からも呼ばれます。認証の対象に入れると、訪問者にもパスワードの入力画面が出たり、これらの機能が動かなくなったりします。ログインしていない訪問者のフォーム送信を admin-post.php で受けるプラグインを使っている場合は、同じ書き方で admin-post.php も外します。

Satisfy Any・Order・Allow from all という書き方は Apache 2.2 のものです。Apache 2.4 では Require all granted を使います。

WordPress の公式ドキュメント（ブルートフォース攻撃への対策のページ）では、/wp-admin/ 全体に Basic 認証をかける方法は Ajax を使うプラグインを壊したり使い勝手を下げたりしやすい古い方法として扱われ、ログイン試行の制限、二段階認証、IP アドレスでの制限などが紹介されています。Basic 認証を使う場合は、上のように除外を入れたうえで、サイトの機能が動くかを確かめてください。

wp-login.php を保護する場合

ログイン画面の wp-login.php は wp-admin フォルダーではなく WordPress のルートにあるため、wp-admin/.htaccess では守られません。ルートの .htaccess に次を追加します。WordPress が書き換える # BEGIN WordPress 〜 # END WordPress の外（上）に書きます。

# ルートの .htaccess（# BEGIN WordPress より上に書く）
<Files "wp-login.php">
    AuthType Basic
    AuthName "Restricted Area"
    AuthUserFile /home/username/.htpasswd
    Require valid-user
</Files>

wp-login.php には、ログインのほか、ログアウト、パスワードの再設定、パスワード保護した投稿のパスワード入力も届きます。パスワード保護した投稿や会員登録を使っているサイトでは、訪問者にも Basic 認証の入力画面が出るようになる点に注意します。

手順3: 動作を確認する

ブラウザで保護したディレクトリを開き、ID とパスワードの入力を求められること、正しく入力すると中身（WordPress の場合はログイン画面）が表示されることを確かめます。コマンドで確かめる場合は次のとおりです。

# 認証なし: 401 になること
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-admin/

# 認証あり: 401 以外（WordPress のログイン画面への 302 など）になること
curl -s -o /dev/null -w '%{http_code}\n' -u wpuser https://example.com/wp-admin/

# admin-ajax.php は認証なしでも 401 にならないこと（パラメーターなしだと WordPress が 400 を返す）
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-admin/admin-ajax.php

-u wpuser と書くとパスワードの入力を求められます。あわせて、サイトの表側の問い合わせフォームや検索など、admin-ajax.php を使う機能が動くかも試します。

Nginx の場合

Nginx では .htaccess の代わりに、サーバーの設定ファイルに書きます。パスワードファイルは htpasswd で作れますが、Nginx が読めるハッシュ形式はサーバーの crypt() の対応状況に左右されます。迷ったら、-B を付けずに作る（Apache の MD5 形式）か、openssl passwd -apr1 で作ります。

# Apache の MD5 形式でパスワードファイルを作る例
printf 'wpuser:%s\n' "$(openssl passwd -apr1)" | sudo tee /etc/nginx/.htpasswd

/wp-admin/ を保護する設定は次のとおりです。PHP-FPM のソケットのパスや fastcgi の読み込み方は、使っている設定に合わせます（例は Ubuntu の snippets/fastcgi-php.conf を使う書き方です）。

location ^~ /wp-admin/ {
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # admin-ajax.php は認証の対象から外す
    location = /wp-admin/admin-ajax.php {
        auth_basic off;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    # wp-admin の中の PHP もここで処理する
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

ここで大事なのは、location に ^~ を付け、その中に PHP の処理を入れることです。location /wp-admin/ { auth_basic ...; } だけを書くと、/wp-admin/index.php のような PHP ファイルへのアクセスは、サーバー全体の location ~ \.php$ のほうで処理されるため、認証がかかりません。Docker の Nginx で確かめたところ、^~ なしの書き方では /wp-admin/index.php が認証なしで表示され、上の書き方では 401 になり、admin-ajax.php だけが認証なしで通りました。

設定を変えたら、構文を確認してから読み込み直します。

sudo nginx -t && sudo systemctl reload nginx

うまく動かないとき

キャッシュ系のプラグインや CDN を使っている場合、認証の画面や 401 の応答がキャッシュされて動作がわかりにくくなることがあります。確認するときは、ブラウザのシークレットウィンドウや curl を使います。

まとめ

• htpasswd -c -B でパスワードファイルを作り、ドキュメントルートの外に置く
• 保護したいディレクトリの .htaccess に AuthType Basic・AuthUserFile（フルパス）・Require valid-user を書く
• WordPress の wp-admin を保護するときは admin-ajax.php を Require all granted で外す。wp-login.php はルートの .htaccess に <Files> で書く
• Nginx では location ^~ /wp-admin/ の中に PHP の処理を入れないと、PHP ファイルに認証がかからない
• Basic 認証は HTTPS のサイトで使い、ログイン試行の制限や二段階認証とあわせて使う

関連記事

• wp-adminを.htaccessでIP制限する方法
• WordPressの管理画面にBasic認証をかける方法