Web Design Leaves

作成日：2025年05月19日

WordPress ログイン URL

WordPress を https://yoursite.com/ にインストールした場合、デフォルトのログインページの URL は以下のとおりです。

• https://yoursite.com/wp-login.php

上記のほかにも、未ログインの状態で次のような URL にアクセスすると、ログインページ（wp-login.php）へ自動的にリダイレクトされます。※末尾にスラッシュがあってもなくても同じ動作になります。

• https://yoursite.com/wp-admin
• https://yoursite.com/dashboard
• https://yoursite.com/admin
• https://yoursite.com/login.php
• https://yoursite.com/login

ログインページにアクセスすると、以下のような画面が表示されます。

【参考】なぜリダイレクトされるのか？

これらのリダイレクトは、WordPress コアの wp-includes/canonical.php に定義されている wp_redirect_admin_locations() という関数によって処理されます。

この関数は template_redirect アクションにフックされており、アクセスされた URL がログインや管理画面に関連するショート URL だった場合に、適切な URL（通常は wp-login.php や wp-admin/）へリダイレクトするよう設計されています。

/**
* Redirects a variety of shorthand URLs to the admin.
*
* If a user visits example.com/admin, they'll be redirected to /wp-admin.
* Visiting /login redirects to /wp-login.php, and so on.
*
* @since 3.4.0
*
* @global WP_Rewrite $wp_rewrite WordPress rewrite component.
*/
function wp_redirect_admin_locations() {
  global $wp_rewrite;

  if ( ! ( is_404() && $wp_rewrite->using_permalinks() ) ) {
    return;
  }

  $admins = array(
    home_url( 'wp-admin', 'relative' ),
    home_url( 'dashboard', 'relative' ),
    home_url( 'admin', 'relative' ),
    site_url( 'dashboard', 'relative' ),
    site_url( 'admin', 'relative' ),
  );

  if ( in_array( untrailingslashit( $_SERVER['REQUEST_URI'] ), $admins, true ) ) {
    wp_redirect( admin_url() );
    exit;
  }

  $logins = array(
    home_url( 'wp-login.php', 'relative' ),
    home_url( 'login.php', 'relative' ),
    home_url( 'login', 'relative' ),
    site_url( 'login', 'relative' ),
  );

  if ( in_array( untrailingslashit( $_SERVER['REQUEST_URI'] ), $logins, true ) ) {
    wp_redirect( wp_login_url() );
    exit;
  }
}

なぜログイン URL を変更する必要があるのか？

前述の通り WordPress では、ログイン URL が初期状態から誰にでも分かる形で公開されているため、悪意のある第三者によってブルートフォースアタック（総当たり攻撃）を仕掛けられるリスクがあります。

そのため、ログイン URL を変更して、攻撃対象として発見されにくくすることは、WordPress のセキュリティ対策として効果的です。

ただし、WordPress のログイン URL（wp-login.php）はコアに組み込まれており、標準の設定だけでは変更できません。そのため、「WPS Hide Login」などのプラグインを使って、ログインURLを任意のものに変更するのが一般的な方法です。

WPS Hide Login

WPS Hide Login は、WordPress.org の公式ディレクトリに登録されている無料で利用できるプラグインです。2025年時点で 100万件以上のアクティブインストールがあり、レビュー評価も平均★4.8（5点満点中）と非常に高評価です。以下のような特徴があります。

ログインURLを簡単に変更できる

WPS Hide Login は、WordPressのデフォルトのログインURL（wp-login.php）を別のURLに置き換えることができます。設定画面で任意のスラッグ（例：my-sec-login）を入力するだけで、ログインURLがすぐに変更されます。

（例） https://yoursite.com/wp-login.php → https://yoursite.com/my-sec-login

軽量でシンプル

このプラグインは非常に軽量で、余計な機能や管理画面を追加せず、最小限の処理だけで動作します。そのため、パフォーマンスへの影響がほとんどなく、初心者にも扱いやすいのが特長です。

リダイレクトによって不正アクセスを防ぐ

ログインURLを変更すると、/wp-login.php や /wp-admin/ に直接アクセスしても404エラーを返すようになり、攻撃者がログインページに到達できなくなります。

攻撃対象になりやすい「wp-login.php」へのブルートフォースを根本から防止できます。

他のセキュリティプラグインとの干渉が少ない

多くのセキュリティ系プラグインは複数の機能を統合していますが、WPS Hide Login はログインURLの変更に特化しているため、他のプラグインとの競合が起きにくいのも利点です。

ログインURLに Basic 認証を設定

WPS Hide Login で変更したログイン URL に Basic 認証を追加することも可能です。

ただ、WPS Hide Login によって変更されたログインURL（例：/secure-login）は、実際には WordPress が内部で処理する仮想的なパスであり、.htaccess ではアクセス制御ができません。

そのため、PHP 側でログインURLを検出し、Basic 認証の処理を加える必要があります。

これにより、WPS Hide Login によるログイン隠蔽に加え、Basic 認証による二重のセキュリティが実現できます。但し、Basic 認証をログイン URL に設定すると、以下のようなデメリットがあります。

Basic 認証設定によるなデメリット

1. ユーザーにとって手間がかかる
   • ログインや管理画面にアクセスする際に、Basic認証＋WordPressログインの2段階になるため、管理者や投稿者にとって手間が増えます。
2. 外部サービスとの連携に支障が出る可能性
   多くの場合、影響はありませんが、以下のようなケースでは問題が出ることがあります
   • 外部ツールがログイン処理（wp-login.php）経由で何らかの操作を行う場合
   • XML-RPC を使う古いアプリ（スマホアプリなど）が wp-login.php を通る場合
3. WordPressのアプリケーションパスワードが使えなくなる
   • Basic 認証が有効な状態では、REST API や XML-RPC にアクセスする際のアプリケーションパスワードが正しく認識されず、一部のプラグインや外部連携機能が動作しなくなる可能性があります。

.htpasswd ファイル

以下の方法では、Basic 認証の情報（ユーザー名とパスワード）を .htpasswd ファイルに、ユーザー名:ハッシュ化されたパスワード（bcrypt）の形式で保存してあることを前提としています。

.htpasswd ファイルは、Webアクセス可能なディレクトリ内に置かないよう注意してください。

推奨されるのは、ドキュメントルート外の安全な場所（例：/home/youruser/.htpasswds/ など）です。

HTTP 接続ではパスワードが平文で送信されるため、必ず HTTPS 環境で運用してください。

また、この例では、.htpasswd に保存された bcrypt ハッシュと password_verify() を用いて認証を行います。そのため、htpasswd コマンドで生成する場合は -B オプションを指定します。

% htpasswd -nbB baz pass123
baz:$2y$05$SFpz.UticReSds3qPW5ts.SOkI/2LDgMoaTYLpGsD5tFVRZ1hYJzO  

.htpasswd が APR1-MD5 や crypt 形式だと以下のコードでは認証できません。

サンプルコード

以下は、WordPress の functions.php に記述することで、WPS Hide Login で設定したログイン URL（例： secure-login-25_x）に Basic 認証をかけるコード例です。

例えば、スラッグが secure-login-25_x の場合、以下の変数 $target_slug に直接その値を指定することもできますが、その場合、スラッグを変更した場合、変数の値も書き換えなければなりません。

WPS Hide Login で設定したログインのスラッグは、データベースでは、wp_options テーブルに option_name = 'whl_page' として保存されているので、 get_option('whl_page') で取得できます。

また、WPS Hide Login のカスタムログイン URL は仮想的なルートなので、WordPress のルーティングが始まる前に URL を処理するため、init フックを使用する必要があります（template_redirect フックでは動作しません）。

// WPS Hide Login で変更したログイン URL に Basic 認証
add_action('init', function () {

  // WPS Hide Login で設定したログインのスラッグを wp_options テーブルから取得
  $target_slug = get_option('whl_page');

  if (!$target_slug) {
    // 設定されていない場合は何もしない
    return;
  }

  // .htpasswdファイルの絶対パスを指定（実際の環境に合わせて変更してください）
  $htpasswd_file = '/home/youruser/.htpasswds/mydomain.com/passwd/.htpasswd';

  // 現在のURLのパス（クエリを除く）を取得
  $request_path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

  // HTTP認証ヘッダー（401レスポンス）を返す関数
  function wpshl_send_auth_request($message = 'Authentication required.') {
    header('Content-Type: text/plain; charset=utf-8');
    header('WWW-Authenticate: Basic realm="Restricted Login Page"');
    header('HTTP/1.0 401 Unauthorized');
    echo $message;
    exit;
  }

  // スラッグと現在のパスが一致するかチェック（正規表現で末尾のスラッシュの有無も含めて一致を確認）
  if (preg_match('#/' . preg_quote($target_slug, '#') . '/?$#', $request_path)) {

    // 認証ヘッダーが送信されていない場合、認証を要求
    if (!isset($_SERVER['PHP_AUTH_USER']) || !isset($_SERVER['PHP_AUTH_PW'])) {
      wpshl_send_auth_request();
    }

    // ブラウザから送信されたユーザー名とパスワードを取得
    $username = $_SERVER['PHP_AUTH_USER'];
    $password = $_SERVER['PHP_AUTH_PW'];

    $authenticated = false;

    // .htpasswd ファイルの存在と読み込み権限を確認
    if (!file_exists($htpasswd_file) || !is_readable($htpasswd_file)) {
      error_log("htpasswd file not found or not readable: $htpasswd_file");
      header('HTTP/1.0 500 Internal Server Error');
      echo 'Server configuration error.';
      exit;
    }

    // .htpasswd の各行を取得（空行や改行を除く）
    $lines = file($htpasswd_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

    // .htpasswd ファイルの読み込みに失敗した場合
    if ($lines === false) {
      error_log("Failed to load htpasswd file despite file_exists(): $htpasswd_file");
      header('HTTP/1.0 500 Internal Server Error');
      echo 'Server error.';
      exit;
    }

    // .htpasswd ファイルの各行（ユーザー名:ハッシュ）を処理して、該当するユーザー名があるか確認
    foreach ($lines as $line) {
      // ユーザー名とハッシュに分割（.htpasswd にある各行を $user と $hash に分解）
      list($user, $hash) = explode(':', $line, 2);

      // 入力ユーザー名が一致し、パスワードも正しければ認証成功
      if ($user === $username && password_verify($password, $hash)) {
        $authenticated = true;
        break;
      }
    }

    // 認証に失敗した場合
    if (!$authenticated) {
      wpshl_send_auth_request('Invalid credentials.');
    }
  }
});

関連ページ：

• WordPress 特定ページにBasic認証を設定する方法【functions.php使用】
• パスワード暗号化（ハッシュ化）生成サンプル

# --------------------------------------------------
# 環境変数 APP_ENV に local を設定（ローカル環境）
# --------------------------------------------------
SetEnv APP_ENV local

 // .htpasswdファイルの絶対パスを指定（実際の環境に合わせて変更）
$htpasswd_file = '/home/youruser/.htpasswds/mydomain.com/passwd/.htpasswd'; // *** この部分は同じ ***

// 環境変数 APP_ENV の値を取得（未定義なら 'production' 扱い）
$env = getenv('APP_ENV') ?: 'production';

// APP_ENV の値が local（ローカル環境）の場合は .htpasswd ファイルのパスを変更
if ($env === 'local') {
  //実際の環境に合わせて変更
  $htpasswd_file = '/Applications/MAMP/pwd/.htpasswd';
}

Limit Login Attempts Reloaded と組み合わせて

WPS Hide Login でログインURLを変更するだけでも、WordPressのログイン画面を攻撃者の目から隠すことができ、自動化されたブルートフォース攻撃に対する大きな防御となります。

しかし、攻撃者が何らかの方法でログインURLを特定した場合、引き続きブルートフォース攻撃を試みてくる可能性はゼロではありません。

そのような場合に備えて、Limit Login Attempts Reloaded（LLAR）と組み合わせて、さらに強固なセキュリティにすることもできます。

併用で2段階の防御を実現

• WPS Hide Login
  • ログインURLを変更して、攻撃者にログイン画面を見つけさせない「防御の第一段階」。
• Limit Login Attempts Reloaded（LLAR）
  • 万が一ログインページが見つかっても、ログイン試行回数を制限し、不正ログインを試みる攻撃を強制的にブロックする「防御の第二段階」。

WPS Hide Login は「攻撃を受けにくくする」ことに特化していますが、見つかった場合の「攻撃を防ぐ」機能はありません。

一方、LLARは「攻撃が行われた後にブロックする」機能を提供します。

この2つを組み合わせることで、「攻撃されにくくする」＋「攻撃されてもブロックする」という二重の防御が実現し、WordPressサイトのログインセキュリティをより強固にできます。

また、2つのプラグインはそれぞれ独立した機能を提供しており、基本的に競合は起こりません（100%起きないとは言い切れませんが）。

Limit Login Attempts Reloaded の使い方

Limit Login Attempts Reloaded の使い方やインストール方法は以下のページを御覧ください。

• ログイン制限でブルートフォース攻撃を阻止 Limit Login Attempts Reloaded

SiteGuard WP Plugin を使うという選択肢

なるべくプラグインを少なくして管理を簡単にしたいという場合は、WPS Hide Login と Limit Login Attempts Reloaded の2つのプラグインを使う代わりに、SiteGuard WP Plugin というプラグインを使ってログインURL変更＋試行回数制限をまとめて行う方法もあります。

関連ページ：

• SiteGuard WP Plugin でログイン保護