WordPressでユーザー名がバレる理由と対策｜ユーザー列挙攻撃をログから解説【Security Log #5】

WordPressサイトを公開すると、検索エンジンだけでなく、さまざまなBotがアクセスしてきます。
その中には、サイトの構造を調べるセキュリティスキャンBotも含まれます。

サーバーログを観察していると、WordPressサイトに対して「ユーザー名を特定するためのアクセス」が来ていることが分かりました。

これはUser Enumeration（ユーザー列挙）と呼ばれる行為です。

この記事では、実際のアクセスログをもとに、WordPressで行われるユーザー列挙スキャンの仕組みを整理します。

User Enumeration（ユーザー列挙）とは

User Enumerationとは、サイトに存在するユーザー名を特定する行為です。

多くの攻撃では、次のような順番で調査が行われます。

ユーザー名不明 → 攻撃できない
ユーザー名特定 → パスワード攻撃が可能

つまり、ユーザー列挙は多くの場合、ブルートフォース攻撃の前段階として行われます。

WordPressは世界中で使われているCMSのため、こうしたスキャンはインターネット上で常に行われています。

実際のアクセスログ

私のWordPressサイトでも、公開直後に次のようなアクセスが確認できました。

www.vivisec.net 35.224.48.77 - - [23/Feb/2026:02:05:33 +0900]
"GET //?author=1 HTTP/1.1" 302 0 "-"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

www.vivisec.net 35.224.48.77 - - [23/Feb/2026:02:05:34 +0900]
"GET //wp-json/wp/v2/users/ HTTP/1.1" 403 2843 "-" 
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

同一IPアドレスから、わずか1秒以内に2つのURLが確認されています。

/?author=1

/wp-json/wp/v2/users/

これはWordPressのユーザー名を取得するための、代表的な2つの方法です。

方法① authorパラメータによるユーザー列挙

最初のアクセスはこれです。

GET /?author=1

WordPressでは、author パラメータを使うとユーザーの投稿一覧ページにリダイレクトされます。

例えば次のような動作になります。

/?author=1
↓
/author/username/

このリダイレクトによって、ユーザー名（username）がURLから分かる場合があります。

ログでは次のように表示されています。

302

302はリダイレクトを意味するステータスコードです。

つまり、このBotは、「authorパラメータを使ってユーザー名を取得できるか？」を確認していたと考えられます。

方法② REST APIによるユーザー列挙

次にアクセスしているのがこちらです。

/wp-json/wp/v2/users/

これはWordPressのREST APIです。

REST APIとは

REST APIとは、WordPressのデータを外部から取得できる仕組みです。

例えば、次のURLにアクセスすると、WordPressのユーザー情報が表示されることがあります。

/wp-json/wp/v2/users

このAPIは本来、Webアプリや外部サービスがWordPressのデータを利用するための機能です。

しかし、この仕組みを利用してユーザー名を調査するスキャンも存在します。

実際のレスポンスは次のようなJSON形式で返されることがあります。

[
 {
  "id": 1,
  "name": "admin",
  "slug": "admin"
 }
]

このようにユーザー名が取得できるため、攻撃者はこのAPIを利用してユーザー列挙を試みることがあります。

今回のログではレスポンスは 403（アクセス拒否） となっており、REST APIによるユーザー列挙はブロックされています。

このアクセスは危険なのか？

今回のアクセスは攻撃というより、自動スキャンの一部と考えられます。

重要なポイントは次の通りです。

• WordPressではユーザー列挙が試みられることは珍しくない
• これはインターネット上で常に行われている
• 多くの場合は自動スキャナーによる調査

また、ユーザー列挙自体は必ずしも脆弱性攻撃とは限りません。

しかし、ユーザー名が特定されると次のような攻撃につながる可能性があります。

• ブルートフォース攻撃
• パスワードスプレー
• アカウント乗っ取り

そのため、ログを観察してサイトの状況を把握しておくことは重要です。

User Enumeration（ユーザー列挙）への対策

WordPressでは、ユーザー列挙そのものを防ぐ対策と、その後に行われるログイン攻撃を防ぐ対策があります。

例えば、次のような対策がよく使われます。

ユーザー列挙の対策

• REST APIの制限
• author列挙の制限

※補足─ユーザー列挙の露出を減らす方法

ユーザー列挙は完全に防ぐことは難しいですが、簡単に取得されない状態にすることは可能です。

例えば、次のような対策で情報の露出を減らせます。

■ author列挙の制限

add_action('init', function () {
  if (!is_admin() && isset($_REQUEST['author'])) {
    status_header(404);
    exit;
  }
});

実際に私がこの対策を行ったところ、/?author=1のアクセスは404として処理されるようになりました。

■ REST API（ユーザー情報）の制限

add_filter('rest_request_before_callbacks', function ($response, $handler, $request) {
  
  if ($request->get_route() === '/wp/v2/users' || 
      strpos($request->get_route(), '/wp/v2/users/') === 0) {
    
    return new WP_Error(
      'rest_forbidden',
      'Forbidden',
      ['status' => 403]
    );
  }

  return $response;
}, 10, 3);

403で制限し、外部からの取得を防いでいます。

ログイン攻撃（ブルートフォース）の対策

• ログインURL変更
• ログイン試行回数制限
• 二要素認証（2FA）
• 画像認証（reCAPTCHAなど）
• セキュリティプラグインの導入

これらの対策によって、ユーザー列挙後の攻撃リスクを大きく下げられます。

私の環境では、サーバー側のWAF機能によって不審なアクセスがある程度ブロックされています。

ログを見ながら状況を把握できるので、セキュリティの確認もしやすいです。

▶ エックスサーバー公式はこちら

まとめ

WordPressサイトを公開すると、次のようなユーザー列挙スキャンが行われることがあります。

/?author=1
/wp-json/wp/v2/users/

今回のログでも、同一IPからこの2つのURLが確認されました。

これはWordPressサイトを調査するための、典型的なスキャン手法です。

サーバーログを確認すると、こうしたBotの挙動が見えてきます。

ログ観察は、サイトがどのようにスキャンされているのかを理解する良い手がかりになります。