WordPressのユーザー名がバレる｜隠す設定と11か所の実測結果

著者: 佐藤優太（Web制作事業 MOVON 代表） ｜ 公開日: 2026-08-15 ｜ 最終更新日: 2026-08-17
この記事は筆者が実際に契約・操作して計測した結果に基づいています。計測条件・計測日・証跡は本文中に明記しています。
本サイトの編集方針: 運営者情報

結論（先に答え）

• WordPressは初期状態のままだと、ログインユーザー名が外部から取得できてしまう経路が複数ある。代表的なのが REST API の /wp-json/wp/v2/users と、?author=1 のリダイレクトである
• 対策を入れたあと、外部から11エンドポイントを計測したところ、ユーザー一覧系の4エンドポイントはすべて 401 を返した【実測: n=1, 2026-08-14, 外部からのHTTPステータス計測】
• ?author=1・?author=2 は 302 を返し、リダイレクト先のURLにユーザー名は含まれていなかった【実測: n=1, 2026-08-14, Locationヘッダの確認】
• 一方で、トップページ・個別記事・固定ページ・フィードはすべて 200 のままで、表示側に副作用は出ていなかった【実測: n=1, 2026-08-14, 同上】
• 重要な注意として、この対策は「ユーザー名を隠す」ものであって、ログイン試行そのものを止めるものではない
• 【2026-08-17 追記】 この記事は1か所見落としていました。 11エンドポイントに /author/<スラッグ>/ が入っておらず、そこは 200で開いていました。しかもスラッグはJSON-LD・記事フッタ・RSSに平文で書かれていたので、推測する必要すらない状態でした【実測: n=6, 2026-08-17, 記事2本・固定ページ・RSS・トップ・著者アーカイブを匿名curlで確認】。原因と直し方は下の追記に書きます

ユーザー名を隠す設定を入れただけでは、バレていないか分からない

セキュリティ設定の記事はたくさんありますが、その多くは「この項目をONにしましょう」で終わっています。

しかし、設定画面のチェックボックスをONにしたことと、外から見て実際に塞がっていること は別の話です。プラグインの除外設定が効いていたり、別のプラグインが経路を開け直していたりすると、ONにしても塞がりません。

そこで、設定したあとに 外部から実際に叩いて確認 しました。以下はその結果です。

ユーザー名を隠すために入れた設定

この種の機能は、日本語圏で広く使われる SiteGuard WP Plugin などが提供しています。なお、本サイトが実際にどのプラグインをどのような構成で使っているかは、後述するログインURLと同じ理由（防御構成の開示になるため）で明記しません。

設定した順序に意味がある

ここは実際にやってみて気づいた点です。順序を間違えると塞がりません。

1. ユーザー名漏えい防御を先に入れ、パーマリンクの変更を後にした。 パーマリンクを先に変えると /wp-json/ の経路が新規に開通し、その状態で放置される時間ができてしまうためです
2. エディタの設定を先に済ませてから、REST APIを無効化した。 ブロックエディタはREST APIに依存しているため、先に無効化すると編集画面が動かなくなる恐れがあります

ログインURLの変更について（本記事で扱わないこと）

WordPressのセキュリティ設定として、ログインページを既定の /wp-login.php 以外のURLに変更する方法がよく紹介されます。

本サイトでもログインURLは変更していますが、どの手段で変更したのか、変更後のURLが何かは公開しません。 この対策は「URLが知られていないこと」でのみ成り立つため、公開した時点で意味がなくなるからです。

同じ理由で、以下の計測結果にも変更後のログインページに関する行は掲載していません。ログインURLの変更を検討している方は、一般に公開されているセキュリティプラグインのドキュメントをご確認ください。

計測結果（11エンドポイント）

計測条件: 外部ネットワークから curl 8.21.0 でHTTPステータスを取得。ログイン状態なし。各エンドポイント1回ずつ【実測: n=1, 2026-08-14, 外部からのHTTPステータス計測】。

ユーザー情報が漏れる経路（塞がっているべきもの）

REST APIのレスポンス本文は次のとおりでした【実測: n=1, 2026-08-14, レスポンス本文の取得】。

{"code":"rest_disabled","message":"The REST API on this site has been disabled.","data":{"status":401}}

表示側に副作用が出ていないか（開いているべきもの）

セキュリティ設定は、締めすぎるとサイトそのものが壊れます。塞いだ後に「壊れていないこと」も確認しました。

?author=1 のリダイレクト先は必ず確認すること

ここが一番の落とし穴だと思います。

?author=1 にアクセスすると、WordPressは通常その投稿者のアーカイブページへリダイレクトします。このとき、リダイレクト先のURLに /author/ユーザー名/ という形でユーザー名が入ります。 つまり、302が返ること自体は対策の証明になりません。リダイレクト先を見る必要があります。

今回の計測では、?author=1・?author=2 のリダイレクト先はいずれもサイトのトップページで、URLにユーザー名は含まれていませんでした【実測: n=1, 2026-08-14, Locationヘッダの確認】。

確認方法は次のコマンドです。ステータスコードだけでなく、Location ヘッダを見てください。

curl -s -o /dev/null -D - "https://example.com/?author=1" | grep -i "^location:"

自分のサイトでWordPressのユーザー名がばれていないか確認する手順

この確認は、必ずご自身が管理するサイトに対してのみ実施してください。 他人のサイトに対して行うと、意図にかかわらず不正アクセスを目的とした調査行為とみなされる可能性があります。

ブラウザのアドレスバーに次のURLを入れるだけでも、ある程度は確認できます。

1. https://自分のドメイン/wp-json/wp/v2/users … ユーザー名やスラッグの一覧が表示されたら 塞がっていません
2. https://自分のドメイン/?rest_route=/wp/v2/users … パーマリンク設定に関係なく届く経路です。1が塞がっていてもここが開いていることがあります
3. https://自分のドメイン/?author=1 … 移動先のURLを見てください。/author/なにか/ になっていたら、その「なにか」がユーザー名です

2番目を確認していない記事が多いように感じます。/wp-json/ を塞いだつもりでも ?rest_route= から取れることがあるため、両方を確認してください。

なお、この問題はレンタルサーバーの「かんたんインストール」で作ったWordPressで特に起きやすいです。当サイトが複数のレンタルサーバーで自動インストールを試したところ、既定値のまま完了させると管理者のユーザー名がコントロールパネルのIDと同じ文字列になり、外から読み取れる状態になるケースがありました。どのサーバーでどうだったかは安いレンタルサーバーの無料お試し比較の該当節に記録しています。インストール時にユーザー名を1つ入力するだけで防げます。

追記（2026-08-17）：この記事は1か所見落としていました

公開から2日後、この記事を書いた本人のサイトが、まだユーザー名を漏らしていたことが分かりました。他社のサーバーを調べていて、対照として自分のサイトのHTMLを見たときに気づきました。

見落としていたのは /author/<スラッグ>/ です。

何が起きていたか

上の表で ?author=1・?author=2 は302になっていました。ここで「著者経路は塞がった」と判断したのが誤りでした。WordPressの著者アーカイブには、もう1つスラッグ形式のURLがあります。

そして、そのスラッグは推測する必要すらありませんでした。次の3か所に平文で書かれていたからです【実測: n=6, 2026-08-17, 記事2本・固定ページ・RSS・トップ・著者アーカイブのHTMLを匿名で取得して文字列検索】。

RSSは特に見落としやすい場所です。 記事ページのHTMLだけ確認して「消えた」と判断すると残ります。

原因は「プラグインの設定漏れ」ではなかった

ここが本質です。WordPressは、ユーザーを作ったときに「表示名」「ニックネーム」「スラッグ」の3つをログイン名と同じ値で初期化します。 表示名を設定しないまま運用すると、テーマはログイン名をそのまま著者名として出力します。

つまりこれは、セキュリティプラグインを入れても塞がりません。 プラグインが対象にしているのは ?author=N とREST APIであって、テーマが出力する著者名ではないからです。

筆者のサイトでは、管理者2名とも表示名・ニックネーム・スラッグの3つがログイン名と同一のままでした【実測: n=1, 2026-08-17, 管理画面のユーザー情報を認証済みで取得して確認】。

どう直したか

1. 表示名とニックネームを、ログイン名と関係のない文字列（実名）に変更した → JSON-LD・フッタ・RSSの表示がすべて変わりました
2. スラッグ（user_nicename）も変更した → 旧URLの /author/<ログイン名>/ は 404 になりました

⚠ 2が重要です。 表示名だけ変えても、/author/<旧スラッグ>/ は開いたままです。そしてスラッグは、管理画面のプロフィール編集画面からは変更できません（標準のUIに項目がありません）。

修正後に外から測り直した結果

自分のサイトで確認する手順（この記事の本題に追加してください）

# ★見落としやすい経路：構造化データにログイン名が出ていないか
curl -s "https://自分のドメイン/記事のURL/" | grep -oE '"author"\s*:\s*\{[^}]*\}'

# ★RSSフィードにも出ていないか
curl -s "https://自分のドメイン/feed/" | grep -c "<出てきた名前>"

# ★スラッグ形式の著者アーカイブが開かないか
curl -s -o /dev/null -w "%{http_code}\n" "https://自分のドメイン/author/<出てきた名前>/"

1行目で名前が出たら、それがログイン名である可能性が高いです。 3行目が200なら、著者アーカイブが開いています。

なぜこれを消さずに書き足すのか

この記事は「設定画面のチェックを入れただけでは、塞がっているか分からない」という趣旨で書きました。その記事自体が、外から測る範囲を1か所取りこぼしていました。

11エンドポイントを測って「塞がった」と書いたことは、当時の計測としては本当です。しかし測る範囲を自分で決めている以上、そこに入っていない経路は永久に見つかりません。今回はたまたま他社のサーバーを調べていて気づきました。

同じ理由で、この追記のあとも、まだ見つけていない経路が残っている可能性があります。 今回確認したのも6URLで、サイトの全URLを網羅したわけではありません。

なお、この記事で扱ったSiteGuardの設定は、有効にしたままでもWordPressの編集画面が動くのかという別の疑問につながります。そちらはWordPress REST API無効化でもブロックエディタは動いたで、実際に無効化した状態の投稿画面を触って確かめました。また、自分のサイトを外部から調べるときに使う無料ツール自体が何を送信しているのかが気になる場合は、ラッコツールズは安全？8ツールの通信を実測して検証したで通信内容を記録しています。

この対策の限界（誤解しないために）

ここは正直に書いておきます。

• これはユーザー名を隠す対策であって、ログイン試行を止める対策ではありません。 攻撃者がユーザー名を推測できなくなるだけで、ログイン画面自体は存在します。ログイン回数の制限や画像認証など、別の対策と組み合わせる必要があります
• ログインURLの変更は「隠す」対策です。 URLが知られれば効果はなくなります。強度は元のパスワードに依存します
• <meta name="generator"> からWordPressのバージョンが読み取れる件については、一般論として「バージョンを隠すこと自体は防御にならない」と考えています。 隠しても脆弱性が塞がるわけではなく、期待できるのは自動スキャンの対象から外れる程度の効果です。優先すべきは本体・テーマ・プラグインを更新し続けることだと考えています。この判断には異論があり得ます
• 計測は各エンドポイント1回ずつです。 時間帯やキャッシュの状態によって結果が変わる可能性は否定できません
• REST APIを無効化すると、REST APIに依存するプラグインが動かなくなることがあります。私の環境で副作用が出なかったからといって、どの環境でも安全とは言えません

WordPressのユーザー名についてよくある質問

Q. /wp-json/wp/v2/users を開いて一覧が出ました。これは危険ですか。

A. ログインに使うユーザー名が外部から分かる状態です。パスワードだけが防御になっている状態なので、対策することをおすすめします。

Q. 対策したのに ?author=1 が302を返します。効いていないのですか。

A. 302が返ること自体は問題ではありません。リダイレクト先のURLにユーザー名が含まれていないかを確認してください。含まれていなければ効いています。

Q. REST APIを無効化して大丈夫ですか。

A. 環境によります。ブロックエディタや一部のプラグインはREST APIを使うため、無効化すると動かなくなることがあります。先にエディタやプラグインの構成を決めてから無効化する 順序をおすすめします。無効化したあとは、記事の投稿・編集・表示が問題なくできるかを必ず確認してください。

Q. 変更後のログインURLを記事に書かないのはなぜですか。

A. ログインURLの変更は「知られていないこと」で成り立つ対策だからです。自分のサイトのURLを公開してしまうと、その対策の意味がなくなります。

この記事の測定条件・証跡の詳細は運営者情報・編集方針に記載の方針に従っています。