REST APIって何をしているのかをイメージしよう
WordPress の REST API は、
「ブラウザ以外のもの（アプリ・ツール・スクリプト）が、WordPress と会話するための窓口」です。
URL でいうと、例えばこんな感じです。
https://example.com/wp-json/https://example.com/wp-json/wp/v2/posts
ブラウザで開くと、JSON 形式のデータがずらっと返ってきます。
これは、テーマやプラグイン、外部サービスが「機械的に」WordPress の情報を取得したり操作したりするための仕組みです。
なぜ「REST API の匿名アクセス」が問題になるのか
ログインしていない人でも、いろいろ見えてしまう
デフォルトの WordPress では、
ログインしていない（＝匿名の）ユーザーでも、REST API にアクセスできます。
例えば、
公開済みの投稿一覧
ユーザー情報の一部（表示名など）
は、認証なしで取得できてしまうことがあります。
「公開されている投稿なんだから、別にいいのでは？」と思うかもしれませんが、
REST API 経由だと、
機械的に一気に情報を抜かれる
ユーザー名やスラッグなどをまとめて収集される
といったことが簡単にできてしまいます。
特にユーザー情報は、
ログインIDの候補（ユーザー名）
著者一覧
などのヒントになりやすく、
総当たり攻撃や標的型攻撃の材料にされることがあります。
「人間が見る」のと「機械が一括で抜く」のは別物
同じ情報でも、
人間がブラウザでページを1つずつ見る
のと
機械がAPIから一気に全部抜く
では、意味合いがまったく違います。
REST API の匿名アクセスをそのまま開けておくと、
「サイトに公開されている情報＋α」を
攻撃者が効率よく収集できる状態
になりやすい、というのがポイントです。
「REST API の匿名アクセス制限」とは何をするのか
ログインしていない人のアクセスを制限する
やりたいことを一言で言うと、
ログインしていない人（匿名ユーザー）が
REST API から取得できる情報を制限する
ということです。
極端なパターンだと、
匿名ユーザーからの REST API へのアクセスは全部拒否
ログインユーザーだけが REST API を使える
という形もあります。
もう少し柔らかいパターンだと、
匿名でも一部のエンドポイントだけ許可
ユーザー情報などセンシティブなものは匿名からは見せない
という制御も考えられます。
「REST API を全部止める」わけではない
ここで大事なのは、
REST API 自体を殺す
のではなく
「誰がどこまで使えるか」を制御する
という発想です。
今どきのテーマやプラグインは、
内部的に REST API を使っていることも多いので、
無条件に全部オフ
→ サイトの一部機能が壊れる
というリスクもあります。
だからこそ、
匿名アクセスをどう扱うか
どのエンドポイントを制限するか
を意識して設計することが大事になります。
具体的にどんな情報が「匿名で見えると困りやすいか」
ユーザー情報（著者一覧など）
REST API からは、例えばこんなエンドポイントでユーザー情報が取れます。
/wp-json/wp/v2/users
ここから、
ユーザーID
表示名
スラッグ（多くの場合、ログインIDと同じだったりする）
などが取得できることがあります。
攻撃者からすると、
「このサイトには admin, editor, taro というユーザーがいるな」
と分かるだけで、
ログインIDの候補リストが一気に手に入るわけです。
これは、総当たり攻撃のスタート地点としてはかなりおいしい情報です。
投稿・カスタム投稿のメタ情報
投稿自体は公開されているので、
「見られて困る」という話ではないかもしれません。
ただし、REST API 経由だと、
特定の条件での一覧取得
カスタムフィールドやメタ情報の一部
など、テーマ側では見せていない情報まで
うっかり出てしまうこともあります。
「公開情報だからOK」と思っていても、
構造化された形で一括取得できると、
攻撃者にとっては分析しやすい材料になります。
例題：匿名アクセス制限あり・なしでの違い
制限なしの場合
https://example.com/wp-json/wp/v2/users
にアクセスすると、
ログインしていなくてもユーザー一覧がJSONで返ってくる
ユーザー名やスラッグが丸見え
https://example.com/wp-json/wp/v2/posts
にアクセスすると、
公開投稿が機械的に全部取得できる
攻撃者はここから、
ユーザー名リストを作る
投稿の構造やカスタム情報を分析する
といったことを簡単に行えます。
匿名アクセス制限ありの場合
同じURLにアクセスしても、
匿名ユーザーには 401（認証が必要）や 403（禁止）を返す
あるいは、ユーザー情報だけは出さないようにする
といった制御が入ります。
攻撃者からすると、
「REST API からユーザー情報が取れないな」
「このサイトは匿名APIがかなり絞られているな」
という状況になり、
少なくとも「簡単に情報を抜く」ことはできなくなります。
プログラミングの感覚で捉える「REST API の匿名アクセス制限」
これは「公開APIと認証必須APIを分ける」設計
普通のWebアプリケーションでも、
誰でも叩ける公開API
ログインしている人だけ叩けるAPI
を分けて設計しますよね。
WordPress の REST API も同じで、
本当に誰にでも見せていい情報だけ匿名で許可
ユーザー情報などは認証必須にする
というのが、本来あるべき姿です。
デフォルトの WordPress は、
そのあたりがやや緩めになっている部分もあるので、
「自分のサイトではどこまで匿名に見せるか」
をエンジニアとして決めてあげる必要があります。
「便利さ」と「安全さ」のバランスを取る
REST API は、
ヘッドレス構成
SPA的なテーマ
外部サービス連携
などにとっては、とても便利な機能です。
だから、
REST API は全部危険だから殺そう
という極端な発想ではなく、
匿名での利用範囲を絞る
必要なところだけ認証付きで使う
というバランスを取るのが現実的です。
セキュリティ設計はいつも、
便利さをゼロにする
ではなく
便利さをできるだけ保ちつつ、リスクを減らす
というゲームです。
REST API の匿名アクセス制限も、その一部だと考えると理解しやすいはずです。
まとめ：REST API の匿名アクセス制限は「機械から見える範囲を絞る」設計
「REST API の匿名アクセス制限」というテーマの本質は、
ログインしていない人（＝機械を含む匿名アクセス）が
REST API 経由でどこまで情報を取れるかをコントロールする
ということです。
押さえておきたいポイントは、
REST API は「機械用の窓口」なので、一気に情報を抜かれやすい
特にユーザー情報などは、匿名で見せるべきか慎重に考えるべき
REST API 自体を殺すのではなく、「誰がどこまで使えるか」を設計する
という3つです。
一度、ブラウザで https://あなたのドメイン/wp-json/ を開いてみてください。
「この情報、匿名でここまで見えていて本当にいいのか？」と自分に問いかけるところから、
あなたの WordPress のセキュリティ設計は、また一段深くなっていきます。
