• HOME
  • Apacheでベーシック認証を設定する方法（htpasswd・.htaccess・WordPressでの注意点）

2026年10月12日

  • シェア
  • ツイート

    • 2026年10月12日

    Apacheでベーシック認証を設定する方法（htpasswd・.htaccess・WordPressでの注意点）

    Apache のベーシック認証は、htpasswd でパスワードファイルを作り、AuthType Basic と Require valid-user を設定するだけで有効になります。この記事では、Apache 2.4 での設定手順を、バーチャルホストに書く方法と .htaccess に書く方法の両方で説明し、IP 制限との組み合わせ、WordPress の管理画面やステージング環境を守るときの注意点、動かないときの確認方法までまとめます。

    ベーシック認証の仕組みと使いどころ

    ベーシック認証は、保護されたURLにアクセスすると Apache が 401 応答と WWW-Authenticate: Basic realm="..." ヘッダーを返し、ブラウザがユーザー名とパスワードの入力欄を表示する仕組みです。入力された値は Base64 で符号化されて毎回のリクエストに付きますが、これは暗号化ではありません。HTTPS を使わずに運用すると、通信経路で簡単に読み取られてしまいます。ベーシック認証は HTTPS を有効にしたサイトで使う、と考えてください。

    向いているのは、公開前のステージング環境、社内向けのページ、WordPress の管理画面への「もう1枚の扉」としての利用です。一方で、ログアウトの仕組みが無い（ブラウザを閉じるまで認証情報が保持される）、試行回数の制限が無い、といった弱点があります。会員サイトの本格的なログインには向かないため、用途を絞って使います。

    手順1：必要なモジュールを確認する

    Apache 2.4 では、次のモジュールが組み合わさってベーシック認証が動きます。

    • mod_auth_basic: Basic 方式の認証
    • mod_authn_file: パスワードファイルの照合
    • mod_authz_user: Require valid-user などの判定
    • mod_authz_core: Require ディレクティブ全般

    多くのディストリビューションでは標準で有効です。読み込まれているかは次のように確認します。Debian / Ubuntu 系では a2enmod auth_basic で有効化できます。

    # Debian / Ubuntu
apache2ctl -M | grep -E 'auth_basic|authn_file|authz_user'
# RHEL / AlmaLinux / Rocky Linux
httpd -M | grep -E 'auth_basic|authn_file|authz_user'

    手順2：htpasswdでパスワードファイルを作る

    パスワードファイルはドキュメントルートの外に置きます。公開ディレクトリに置くと、設定ミスがあったときにファイルそのものをダウンロードされるおそれがあるためです。

    # 初回のみ -c（ファイルを新規作成）。-B は bcrypt でハッシュ化する指定
sudo htpasswd -c -B /etc/apache2/.htpasswd admin

# 2人目以降は -c を付けない（付けると既存ファイルが上書きされる）
sudo htpasswd -B /etc/apache2/.htpasswd editor

# ユーザーの削除
sudo htpasswd -D /etc/apache2/.htpasswd editor

# 権限の調整（RHEL 系ではグループを apache に読み替える）
sudo chown root:www-data /etc/apache2/.htpasswd
sudo chmod 640 /etc/apache2/.htpasswd

    htpasswd は Debian / Ubuntu では apache2-utils、RHEL 系では httpd-tools パッケージに含まれます。パスワードは対話式で入力し、コマンドラインの引数に書かないでください（シェルの履歴に残ります）。ファイルにはハッシュ値だけが保存され、平文のパスワードは残りません。-c を2回目以降に付けて既存ユーザーを消してしまうのが、もっとも多い失敗です。

    手順3：バーチャルホストに設定する

    サーバー設定を編集できるなら、.htaccess よりバーチャルホストの設定ファイルに書くほうが、管理しやすく処理も軽くなります。

    <VirtualHost *:443>
    ServerName staging.example.com
    DocumentRoot /var/www/staging

    <Directory "/var/www/staging">
        AuthType Basic
        AuthName "Staging"
        AuthBasicProvider file
        AuthUserFile "/etc/apache2/.htpasswd"
        Require valid-user
    </Directory>

    # SSL の設定は省略
</VirtualHost>

    AuthName はブラウザの入力欄に表示されることがある文字列（realm）です。編集したら構文を確認してから再読み込みします。

    sudo apachectl configtest
sudo systemctl reload apache2   # RHEL 系は httpd

    手順4：.htaccessに設定する場合

    レンタルサーバーなどでサーバー設定を触れない場合は、保護したいディレクトリの .htaccess に書きます。サーバー側で AllowOverride AuthConfig（または All）が許可されていないと、.htaccess の認証設定は無視されるか 500 エラーになります。

    AuthType Basic
AuthName "Restricted"
AuthUserFile "/home/example/.htpasswd"
Require valid-user

    AuthUserFile はサーバー上のファイルシステムのフルパスで指定します。URL や相対パスを書くと見つからずにエラーになります。レンタルサーバーによっては管理パネルからベーシック認証を設定する機能があり、その場合はパネルを使うほうが安全です（画面名や手順は事業者ごとに異なります）。

    手順5：IP制限と組み合わせる

    社内ネットワークからはパスワード無しで入れ、それ以外は認証を求める、という設定は RequireAny で書けます。

    <Directory "/var/www/staging">
    AuthType Basic
    AuthName "Staging"
    AuthUserFile "/etc/apache2/.htpasswd"
    <RequireAny>
        Require ip 203.0.113.0/24
        Require valid-user
    </RequireAny>
</Directory>

    逆に「指定 IP から、かつパスワードも必要」にしたい場合は RequireAll を使います。ロードバランサーや CDN の後ろにある場合、Apache から見える接続元はそれらの IP になるため、mod_remoteip で実際のクライアント IP を復元しないと IP 条件が意図どおりに働きません。

    WordPressで使うときの注意点

    WordPress の管理画面を守る目的では、wp-login.php だけを保護する方法が手軽です。WordPress 本体の .htaccess（ドキュメントルート）に次を追記します。

    <Files "wp-login.php">
    AuthType Basic
    AuthName "Admin"
    AuthUserFile "/etc/apache2/.htpasswd"
    Require valid-user
</Files>

    /wp-admin/ ディレクトリ全体を保護する場合は、admin-ajax.php を例外にしてください。フロント側のフォームや「いいね」ボタンなど、多くのテーマ・プラグインが訪問者のブラウザから admin-ajax.php を呼び出しているため、ここまで認証を求めるとサイトの機能が止まります。wp-admin/.htaccess に次のように書きます。

    AuthType Basic
AuthName "Admin"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user

<Files "admin-ajax.php">
    Require all granted
</Files>

    ステージングサイト全体を保護すると、WordPress 自身がサーバー内部から自サイトへ送るリクエスト（WP-Cron の起動やサイトヘルスのループバック確認）も 401 で拒否されます。サイトヘルスに「ループバックリクエストに失敗」と表示されるのはこのためで、ステージングでは問題にならないことも多いですが、予約投稿などを試す場合は Require ip でサーバー自身の IP を許可するなどの対処が必要です。

    ベーシック認証は WordPress のログイン強化の代わりにはなりません。強いパスワードと二要素認証、ログイン試行の制限を WordPress 側でも行ったうえで、追加の防御として使ってください。ベーシック認証そのものには試行回数の制限が無いため、総当たりが気になる場合は fail2ban の apache-auth フィルターなどでエラーログを監視する方法があります。

    動かないときの確認方法

    設定後は、ブラウザではなく curl で応答を確認すると原因を切り分けやすくなります。

    # 認証なし: 401 と WWW-Authenticate ヘッダーが返れば設定は効いている
curl -sI https://staging.example.com/ | head -n 5

# 認証あり: -u にユーザー名だけを渡すとパスワードを対話入力できる
curl -sI -u admin https://staging.example.com/ | head -n 5

    よくある症状と原因は、起きやすい順に次のとおりです。

    1. 認証画面が出ない: .htaccess が読まれていません。AllowOverride の設定と、ファイル名・設置場所を確認します。キャッシュ系プラグインや CDN が古い応答を返している場合もあります。
    2. 正しいパスワードでも通らない: エラーログ（Debian 系は /var/log/apache2/error.log、RHEL 系は /var/log/httpd/error_log）を見ます。ユーザーが見つからない旨やパスワード不一致の旨が記録されていれば、-c による上書きや別ファイルの参照を疑います。
    3. 500 エラーになる: 構文ミスか、AllowOverride で許可されていないディレクティブです。エラーログに該当行が出ます。
    4. パスワードファイルを開けない旨のエラー: パスの誤りか、Apache の実行ユーザーに読み取り権限がありません。

    いずれの場合も、設定を変えるときは元のファイルをコピーして残しておき、本番では作業前にバックアップを取ってから進めてください。

    まとめ

    • ベーシック認証は htpasswd でファイルを作り、AuthType Basic と Require valid-user で有効にする
    • 認証情報は暗号化されないため、HTTPS とセットで使う
    • パスワードファイルはドキュメントルートの外に置き、2人目以降は -c を付けない
    • IP 制限は RequireAny / RequireAll で組み合わせる。プロキシの後ろでは mod_remoteip が必要
    • WordPress では wp-login.php を保護するか、wp-admin を保護する場合は admin-ajax.php を例外にする
    • 確認は curl で 401 と WWW-Authenticate を見て、通らなければエラーログを読む（2026年10月現在の Apache 2.4 系を前提にしています）
    Views: 63

    お気軽にご相談ください

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