Sorabun

セキュリティ

WordPressのREST API、外から何が見える？ 手元のサイトで実際に調べてみた【2026年】

公開 ・ 読了の目安 約19分 ・ Sorabun 編集部

WordPressのREST API、外から何が見える？ 手元のサイトで実際に調べてみた【2026年】

「WordPressのREST APIは、ユーザー名が丸見えになるから止めたほうがいい」。そんな話をよく見かけます。

本当に、外から何が見えるのでしょうか。私たちは、手元に新しくWordPressを立てて、ログインしていない状態で、REST APIに実際に聞いてみました。試したのは自分たちの手元のサイトだけで、ほかのサイトには一切アクセスしていません。

先に結論を書きます。

1. なぜ今、APIが話題なのか

2026年の秋、国内で相次いだ情報漏えいで、「API」という言葉が何度も出てきました。

10月15日、ソースネクストは、第三者が「会員情報取得APIを不正に利用」して、登録者の情報を取得したと発表しました。対象は22,519,960件です。

ソースネクストの発表の経緯の部分。10月9日10時頃から不正アクセスがあり、会員情報取得APIを不正に利用し、お客様の情報を取得したことが判明した、対象件数は22,519,960件と書かれている
ソースネクストの発表（2026年10月15日）

JPCERT/CCも、10月8日の注意喚起で、相次ぐ不正アクセスの手口の1つに「ケースB：API経由での不正な操作」を挙げました。公開しているスマートフォンアプリを解析してAPIの入口や鍵を特定し、本来は画面からはできない操作（ユーザー権限の変更、不正なアカウントの作成など）をする、というものです。

JPCERT/CC の注意喚起のケースB。一般公開しているスマートフォンアプリを解析しAPIのエンドポイントやキーを特定する、本来画面操作では実行できない内部APIに対する攻撃、他のシステムの侵害で窃取したAPIキーを使用する、と書かれている
JPCERT/CC 注意喚起（2026年10月8日公開・9日更新）の「ケースB」

NICTも10月13日、他人のIDに変えるだけで情報が取れてしまう欠陥（IDOR／BOLA）の点検と、2026年8月以降のアクセスの記録の確認をすすめています。

ただし、これらはどれも、スマートフォンアプリの裏側に各社が独自に作ったAPIの話です。WordPressが使われていた、という発表はありません。 それでも、「入口ごとに、誰が使ってよいかを確かめる」という考え方は、WordPressのREST APIにもそのまま当てはまります。

2. WordPressのREST APIとは

REST APIは、記事やユーザーなどの情報を、プログラムから読み書きするための窓口です。WordPressには、2015年の4.4で土台が、2016年12月の4.7で記事・コメント・ユーザーなどを扱う標準の入口が入りました。

WordPress REST API Handbook のトップ。REST API はアプリケーションが JSON で WordPress サイトとやり取りするための仕組みで、WordPress のブロックエディターの土台だと書かれている
WordPress REST API Handbook のトップ

公式の説明書には「ブロックエディターの土台（the foundation of the WordPress Block Editor）」と書かれています。WordPress本体のサイトヘルスにも「ブロックエディターの画面は、投稿や固定ページの表示や保存のためにREST APIを使用しています」とあります。記事を書く画面そのものが、この窓口を使っているわけです。

3. 実際に聞いてみた：ログインせずに見えるもの

試した環境

入口の一覧は、誰でも見られる

サイトのアドレスの後ろに /wp-json/ を付けて開くと、入口（ルート）の一覧が出ます。プラグインを入れていない状態で、ログインしていなくても、133本の入口と、5つの名前空間（oembed/1.0・wp/v2・wp-site-health/v1・wp-block-editor/v1・wp-abilities/v1）が見えました。

手元の WordPress 7.1.3 で /wp-json/ を開いた結果をまとめたカード。初期設定で入口は133本、名前空間は5つ
手元の WordPress 7.1.3（プラグインなし）に、ログインせずに聞いた結果

見えるもの・見えないもの

ログインせずに REST API で見えるものと見えないものの表。公開した記事・画像のURL・コメントの名前は見える、記事を書いたユーザーの名前とログイン名は見える（要注意）、下書き・非公開のページ・記事の無い会員・サイトの設定・アプリケーションパスワードは見えない
手元の WordPress 7.1.3（プラグインなし）で、実際に聞いた結果
聞いたもの 結果
公開した記事・固定ページ 見える（もともと公開しているもの。本文・日付・書いた人のIDなど）
画像 見える（URLなど）
承認済みのコメント 名前とアバターのURLは見える。メールアドレスは出ない（アバターのURLには、メールアドレスから作ったハッシュが入る）
下書き・非公開のページ 見えない（400：無効なパラメータ）
サイトの設定 見えない（401）
アプリケーションパスワード 見えない（401）
記事の無い会員（購読者） 見えない（401）
記事を書いたユーザー 見える。ログイン名も分かる（次の節）

本体は、見せてはいけないものを、きちんと隠していました。

ユーザーの一覧に、ログイン名が出る

/wp-json/wp/v2/users を開くと、記事を書いた2人が出てきました。表示名（name）に加えて、slug という項目があり、そこにログイン名がそのまま入っていました。

ユーザーの一覧の返事をまとめたカード。初期設定のままでは記事を書いた2人が出て、slug にログイン名の demo と editor-taro が入っている。右は Sorabun でふさいだ後で、404（rest_no_route）
手元の WordPress 7.1.3。返ってきた中身を見やすく整えた（右は、8章の設定をした後）

理由はWordPressの作りにあります。slugは、何も変えなければログイン名から作られます。表示名も、名前を入れていなければログイン名になります。なお、一覧に出るのは「公開した記事がある人」だけで、記事の無い購読者は出ませんでした（WordPress 4.7.1で、REST APIに出す種類の投稿がある人に絞られました）。

表示名を変えても、ログイン名は分かる

管理者の表示名を「サイト管理者」に変えてみましたが、slugは元のログイン名のままでした。slugは、普通の管理画面からは変えられません。

さらに、ログインしていなくても ?search= でユーザーを検索でき、ログイン名で検索すると、その人が見つかりました（WordPressのソースコードでも、ログインしていない人の検索の対象に、ログイン名の列が入っています）。

表示名を変えてもログイン名が分かることを示すカード。表示名を「サイト管理者」に変えても slug は demo のまま、ログイン名 editor-taro で検索するとその人が見つかる
手元の WordPress 7.1.3。ログインせずに試した結果を見やすく整えた

表示名を変えるだけでは、ログイン名は隠せません。また、テーマによっては、記事の著者のリンク（/author/○○/）にも、同じslugが出ます。

4. ログイン名は秘密？ WordPressの公式の立場

では、これは欠陥なのでしょうか。WordPressの公式の立場は「違う」です。

Core Contributor Handbook の「Why are disclosures of usernames or user IDs not a security issue?」。WordPress はユーザー名やユーザーIDを秘密の情報とは考えていない、REST API のユーザー一覧が誰でも見られるのは意図したもの、と書かれている
Core Contributor Handbook「Reporting Security Vulnerabilities」

開発に参加する人向けの手引きには、次のように書かれています（要約）。

つまり、ログイン名は「表札」のようなものです。表札が見えても、鍵が無ければ入れません。守りの本体は次の3つです。

  1. 強いパスワード（使い回さない）
  2. 2段階認証
  3. ログインの総当たりの回数を絞る

ログイン名を隠すのは、その上に重ねる一手と考えるのがよさそうです。総当たりで当てなければいけないものが「ログイン名とパスワード」の2つになるので、手間は増えます。

5. 本当に危ないのは、プラグインが足した入口

人気のプラグインを3つ入れると、入口は735本に

手元のサイトに、Contact Form 7（6.2.2）・Yoast SEO（28.7）・WooCommerce（11.2.1）の3つを入れて、もう一度 /wp-json/ を開きました。入口は、133本から735本に増えました。

人気のプラグインを3つ入れたときの入口の数をまとめたカード。133本から735本に増え、増えた名前空間は wc/v3（112）、wc-admin（97）、wc-analytics（89）、wc/v2（72）、yoast/v1（66）、wc/v1（49）、wc/store（31）、wc/store/v1（31）、jetpack/v4（18）、wccom-site/v3（8）、contact-form-7/v1（6）、wc-admin-email（5）
手元の WordPress 7.1.3 に、人気のプラグインを3つ入れて聞いた結果

一覧には、入っているプラグインの名前空間（名前）も出ます。公式の説明書にも、プラグインが入口を登録すると、その名前空間が一覧に加わると書かれています。この一覧を使って、入っているプラグインを調べる公開ツールもあります。

入口が増えること自体は悪くありません。ただ、入口が増えるほど、どこか1つに「鍵のかけ忘れ」がある可能性も増えます。

鍵のかけ忘れは「破滅的になり得る」

プラグインがREST APIに入口を足すときは、「誰が使ってよいか」を確かめる関数（permission_callback）を付けることになっています。WordPress 5.5の開発者向けのお知らせは、これを付け忘れると、誰でも使える入口になってしまうと説明しています。

Make WordPress Core の「Warn when omitting a permission_callback」。permission_callback の無いルートは公開として扱われ、付け忘れや書き間違いで誰でも使えるようになる、実際に何度も起きていて、結果は破滅的になり得る、と書かれている
Make WordPress Core「REST API changes in WordPress 5.5」（2020年7月22日）

Such a scenario has happened multiple times in the wild, and the results can be catastrophic when it occurs. （こうしたことは実際に何度も起きていて、起きたときの結果は破滅的になり得る）

5.5からは、付け忘れると開発者向けの警告が出るようになりました。ただし、警告が出るだけで、入口そのものは登録されてしまいます。

なお、誰でも使える入口が、すべて危ないわけではありません。Contact Form 7のフォームの送信のように、わざと誰でも使えるように作った入口もあります。問題になるのは、その先で、大事なデータや操作に触れてしまうときです。

2026年の実例：Gravity SMTP

2026年の実例が、メール送信のプラグイン「Gravity SMTP」（2.1.4以前）の脆弱性（CVE-2026-4020）です。

CrowdSec の CVE-2026-4020 の報告。Gravity SMTP の情報漏えいの脆弱性が3月31日に公表され、最初の実際の攻撃は5月27日に観測、6月1日までに412の攻撃元のIPを確認した、と書かれている
CrowdSec（CVE-2026-4020、Gravity SMTP）

セキュリティ会社のCrowdSecは、最初の実際の攻撃を5月27日に観測し、6月1日までに412の攻撃元を確認したと書いています。報道によると、Wordfenceは1,700万回以上の攻撃を防いだとしています。深刻度（CVSS）は、CVEの記録では7.5、報道では5.3とされていて、食い違っています。

ほかにも2026年には、数字のIDを順番に変えるだけで他人の口座情報が読めた会計プラグイン（Devs Accounting、CVE-2026-9175）など、REST APIの入口の権限の確認が抜けていた脆弱性が見つかっています（公表の時点で、攻撃の報告は無いもの）。1章のNICTの注意喚起にあった「他人のIDに変えるだけで取れてしまう欠陥」と同じ形です。

参考：本体のREST APIが狙われた例（2026年7月）

2026年7月には、WordPress本体のREST API（まとめて送る batch の入口）を使った攻撃の連鎖（wp2shell、CVE-2026-63030 ほか）が、実際の攻撃に使われました。WordPress 7.0.2（7月17日）で修正され、WordPress.orgは自動更新で強制的に配りました。米国のCISAは7月21日に「悪用が確認された脆弱性」の一覧に載せ、IPAも7月22日に注意喚起を出しています。7.1系は、正式版の前に修正済みです。本体を最新に保つことの大切さが分かる例です。

6. REST APIは止めればいい？

公式は「無効にしないで」

REST API Handbook の「Can I disable the REST API?」。REST API を無効にしてはいけない、管理画面の機能が壊れる、代わりにフィルターで認証を必須にできる、と書かれている
WordPress REST API Handbook「Frequently Asked Questions」

公式の説明書は「REST APIを無効にしてはいけない。APIに頼っている管理画面の機能が壊れる」と書いています。代わりに、rest_authentication_errors というフィルターで、ログインしていない人にはREST APIを使わせない方法を案内しています。

全部ログイン必須にすると、フォームが送れない

手元のサイト（Contact Form 7を入れたもの）で、公式の説明書のとおりに「全部ログイン必須」にしてみました。すると、ログインしていない訪問者が問い合わせフォームを送ると、401（「現在ログインしていません。」）が返り、送れなくなりました。フォームの送信にも、REST APIが使われているからです。

全部ログイン必須にしたときの違いをまとめたカード。そのままではフォームの送信が200で受け付けられるが、全部ログイン必須にすると401（rest_not_logged_in）になり、訪問者が問い合わせを送れなくなった
手元の WordPress 7.1.3 ＋ Contact Form 7。公式の FAQ にある方法で試した

REST APIを止めるなら、どの入口を止めるかを選ぶ必要があります。丸ごと止めると、フォームや、プラグインの機能が壊れることがあります。

7. REST APIを止めずに、今日やること

  1. 使っていないプラグインを消す。 入口が減ります。止めるだけでなく、消してください
  2. プラグイン・テーマ・本体を、最新に保つ。 Gravity SMTPも、wp2shellも、修正版で直っています
  3. ログイン名は隠しつつ、強いパスワードと2段階認証を固める。 ログインの総当たりの回数も絞ります
  4. アプリケーションパスワードを見直す。 「ユーザー → プロフィール」の下に、心当たりの無いものや、使っていないものが無いか確かめ、あれば取り消します
  5. アクセスの記録を確かめる。 /wp-json/ への短時間の大量のアクセスや、IDを順番に変えたアクセスが無いか。NICTは、2026年8月以降の記録の確認をすすめています

自分のサイトで何が見えるかは、ログアウトした状態（または別のブラウザ）で、自分のサイトの /wp-json/wp/v2/users を開けば確かめられます。

8. ソラブンでできること

ソラブンを入れたWordPressなら、管理画面の「Sorabun → セキュリティ / 高速化」の「ユーザー名の漏れ」をオンにするだけで、ログインしていない人に対して、次の道をふさげます。

Sorabun のセキュリティ画面の「ユーザー名の漏れ」の設定。?author=1 を開くとログインIDが分かる仕組みと、REST API のユーザー一覧・サイトマップのユーザー一覧を、ログインしていない人には出さない。著者ページはそのまま表示される
ソラブンを入れた手元の WordPress のセキュリティ画面

手元で試すと、ユーザーの一覧は「見つからない（404）」という返事に変わりました。REST APIのほかの入口は止めないので、ブロックエディターやフォームには影響しません。著者のページ（/author/○○/）はそのまま表示されるので、気になる場合はテーマ側で著者のリンクを出さない設定にしてください。

同じ画面で、ログインの総当たりの回数の制限、2段階認証、ほかのサイトから漏れたパスワードを使わせない設定もできます。入っているプラグインの既知の脆弱性を毎日調べて、急ぐ修正だけを自動で当てることもできます。

なお、ソラブン自身が足しているREST APIの入口（sorabun/v1）も手元で確かめました。記事・ジョブ・MCPの入口は、ログインしていない人には401を返します。決済の通知の受け口（stripe）は、外から呼ばれる前提の入口なので、Stripeの署名を確かめ、署名の無い呼び出しは400で断ります。

よくある質問

REST APIを無効にするプラグインを入れたほうがいいですか？

丸ごと無効にするのは、WordPressの公式がすすめていません。管理画面の機能や、フォームなどのプラグインが壊れることがあります（手元では、全部ログイン必須にしただけで、Contact Form 7のフォームが送れなくなりました）。止めるなら、ユーザーの一覧のように、止めても困らない入口だけを選んでください。

ログイン名が見えると、乗っ取られますか？

ログイン名だけでは入れません。WordPressの公式も、ユーザー名は秘密の情報ではないという立場です。強いパスワード・2段階認証・総当たりの回数の制限がそろっていれば、ログイン名が分かっても入られにくくなります。隠すのは、その上に重ねる一手です。

/wp-json/ の一覧を隠せば安全ですか？

一覧を隠しても、入口そのものは、アドレスを直接指定すれば呼べます。守りの基本は、それぞれの入口で「誰が使ってよいか」を確かめること（プラグインを最新に保ち、使わないものは消すこと）です。

下書きや、コメントのメールアドレスは見えてしまいますか？

手元のWordPress 7.1.3では、ログインしていない人には、下書き・非公開のページ・コメントのメールアドレスは見えませんでした。ただし、プラグインが足した入口では、プラグインの作り次第です。

まとめ

出典（2026年10月19日に確認）

CrowdSec・Wordfence は、セキュリティの製品を販売する会社です。Wordfence の数字は報道によるものです。「試した」と書いた結果は、すべて手元に立てたWordPressでのものです。

関連するコラム

セキュリティ 【2026年】WordPressの保守・セキュリティ対策を徹底解説！ 2026年はWordPress本体の重大な脆弱性（wp2shell・CVE-2026-87902）が続きました。数字で見るいまの状況、まず5分でできる確認、今日からの基本の対策、保守のスケジュール、乗っ取りのサインと初動まで、一次情報をもとに解説します。 セキュリティ WordPressはオワコン？ 脆弱性を実際に数えて、初期設定も検査してみた【2026年10月】 「WordPressはオワコン」は本当か。プラグインを作る私たちが、都合の悪い数字も含めて検証しました。シェアの推移、開発の状況、脆弱性を年ごとに数えた結果（本体は1%未満）、2026年の本体の悪用と強制更新、初期設定のWordPress 7.1.3の検査、乗り換え先との比較まで。 セキュリティ 【2026年】相次ぐ個人情報漏えい、何が起きている？ 原因の「事実」と今日やる対策 2026年9月から相次ぐ個人情報の漏えい（タイムズカー・ローソン・ソースネクストほか）。何が起きているのかを各社の発表と国の機関の資料で整理し、確認された手口、「AIのせい」は本当か、漏れたら個人が今日やること（免許証の本人申告）、サイトを持つ人の対策までまとめました。

コラムの一覧へ