WordPressのREST API、とくに /wp-json/wp/v2/users によるユーザー情報取得は、昔から知られている仕様です。そのため「これは脆弱性ではない」「仕様だから問題ない」といった認識のまま、特に対策されずに運用されているケースも少なくありません。
しかし最近、この“昔からある仕様”が、再びセキュリティ上のリスクとして注目される状況が増えてきています。
なぜ今、再び問題として浮上しているのか
大きな理由は、環境の変化です。特に次の3つが影響しています。
- 攻撃の自動化・高度化
- REST APIの利用増加
- プラグイン連携による情報露出の増加
最近はBotによるスキャンが一般化しており、/wp-json/ 以下を機械的に探索するアクセスが増えています。これは単なる情報取得ではなく、ユーザー列挙 → ログイン試行 → 不正アクセスといった攻撃チェーンの入口として利用されるケースが増えているためです。
WordPressが“APIサーバー”として使われ始めた
もう一つの大きな変化が、Headless CMSの普及です。現在ではフロントエンドとバックエンドを分離し、WordPressをAPIとして利用する構成が一般的になりつつあります。
- フロント：Next.js / React
- バックエンド：WordPress（REST API）
つまり、WordPressは「Webサイト」ではなく「APIサーバー」として使われるケースが増えているということです。この変化により、公開APIそのものが攻撃対象になりました。
「仕様」が「リスク」に変わる瞬間
REST API自体は仕様ですが、使われ方によってはリスクになります。例えば、ユーザー一覧取得によるログインID特定や、公開APIを利用した情報収集、カスタムデータの過剰出力による情報漏洩などです。
これらは単体では問題なくても、組み合わさることで実害につながるというのが現在の状況です。
プラグインと連携した“意図しない情報公開”
最近特に多いのが、プラグインによる情報拡張です。ACFなどで追加したカスタムフィールドやユーザーメタ情報が、そのままREST API経由で公開されてしまうケースがあります。
その結果、本来公開するつもりがなかった情報まで外部から取得可能になることがあります。
よくある誤解：「公開しても問題ないはず」
現場では「フロントで使っているだけだから問題ない」「重要な情報は出していない」といった認識がよく見られます。しかし実際には、攻撃者は断片的な情報を組み合わせて利用します。
例えばユーザー名だけでも、ログイン攻撃の成功率は大きく上がります。
とりあえず対策：usersエンドポイントを非公開にする
ここまで読んで、「まず何をすればいいのか？」と思った方もいると思います。実際に自分のサイトで /wp-json/wp/v2/users にアクセスできてしまった場合、ひとまずの対策としてこのエンドポイントを無効化する方法があります。
functions.php に以下のコードを追加してください。
|
1 2 3 4 5 6 |
add_filter('rest_endpoints', function ($endpoints) { if (isset($endpoints['/wp/v2/users'])) { unset($endpoints['/wp/v2/users']); } return $endpoints; }); |
この設定により、未認証ユーザーからのユーザー一覧取得を防ぐことができます。
なお、Headless CMS構成などでユーザー情報をAPI経由で利用している場合、この設定により機能に影響が出る可能性があります。ただし、一般的なWebサイトで影響が出るケースはほとんどありません。
ただしこれはあくまで暫定的な対応です。REST API全体の設計や、他のエンドポイントの公開範囲も含めて見直すことが重要です。
ここまでのまとめ
ここまでの内容を整理すると、REST APIは昔からある仕様ですが、現在は利用環境が変化しており、その結果リスクとしての意味が変わっていると言えます。
つまり問題は、「新しい脆弱性」ではなく「使われ方の変化」です。
ここからは少し技術的な内容になりますが、実際にどのような設定や実装がリスクになるのかを見ていきます。
セキュリティ観点で見ると何が問題なのか
この問題はOWASPの観点でも整理できます。特に「情報漏洩」「設定ミス」「認証不備」に関係します。
| 分類 | 内容 |
|---|---|
| A02 | 情報漏洩（Sensitive Data Exposure） |
| A05 | 設定ミス（Security Misconfiguration） |
| A07 | 認証不備（Authentication Failures） |
特に多いのは、設定ミスによる公開APIの過剰露出です。
よくある実装ミス：permission_callback
WordPressでREST APIを実装する際、重要なのがpermission_callbackです。ここを誤ると、意図せず公開APIになります。
|
1 2 3 4 5 |
register_rest_route('myapi/v1', '/users', [ 'methods' => 'GET', 'callback' => 'get_users', 'permission_callback' => '__return_true' ]); |
この設定は、誰でもアクセス可能なAPIを意味します。本来は認証チェックを行うべきです。
|
1 2 3 |
'permission_callback' => function () { return is_user_logged_in(); } |
実際にREST APIを使った実装例（Udemy講座より）
ここまで解説してきた内容は、実際の開発現場でもそのまま問題になります。特にREST APIを使った機能開発では、設計ミスがそのまま脆弱性につながるケースが少なくありません。
例えば、私がUdemyで公開しているWordPressプラグイン開発講座では、「リアルタイムな記事検索機能」をREST APIを使って実装しています。
この機能では、JavaScriptからWordPressのAPIを叩き、検索結果を即時表示する構成になっています。いわゆるHeadless的な実装パターンです。
その中で、あえてpermission_callbackの設定を変えた場合にどうなるかという実験も行っています。
- permission_callback を __return_true にした場合
- 認証チェックを入れた場合
- どこまでのデータが取得できてしまうのか
こうした違いを実際に確認すると、「設定一つで公開APIの性質が大きく変わる」ことがよく分かります。
また、検索機能という性質上、ユーザー入力を扱うため、入力値の扱い方やレスポンス設計もセキュリティに直結します。
このように、REST APIは便利な反面、実装＝そのまま公開インターフェースになるという前提で設計する必要があります。
もし興味があれば、「WordPress REST API プラグイン開発」などで調べてみるか、実際に手を動かして試してみると理解が深まります。
出力データは“最小化”する
もう一つ重要なのがレスポンス設計です。オブジェクトをそのまま返す実装は、不要な情報まで公開してしまうリスクがあります。
代わりに、必要な項目だけを明示的に返すことが重要です。
|
1 2 3 4 |
return [ 'id' => $user->ID, 'name' => $user->display_name ]; |
実務でやるべき“再評価ポイント”
現場では次のポイントを確認してください。
- 公開しているREST APIを把握しているか
- permission_callbackが適切に設定されているか
- 不要なデータを出力していないか
これらを見直すだけでも、リスクは大きく低減できます。詳しくは「WordPress REST API セキュリティ」「permission_callback」などで調べてみてください。
まとめ：問題は「新しさ」ではなく「使われ方」
今回のポイントは、仕様は変わっていないが、環境が変わったという点です。
そして現在、WordPressは“Webサイト”ではなく“APIサーバー”として扱われ始めています。だからこそ、これまで問題にならなかった仕様も、改めて見直す必要があるフェーズに入っています。
一度、自分のサイトのREST APIを確認し、「公開しても問題ないか？」という視点で見直してみてください。
