二つの仕組みの使われ方
XML-RPCは外部投稿や一部の連携に使われます。REST APIはブロックエディターや製品連携などでも使われます。実際の利用者とアクセス先を調べ、機能名だけで「全て不要」と判断しないことが重要です。
無効化設定の意味を確認する
xmlrpc_enabledをfalseにする設定は、XML-RPCの全ての通信をWebサーバーで拒否する設定と同じではありません。認証を伴う機能、pingback、エンドポイントへのアクセスを分けて確認します。RESTも公開データの取得と権限が必要な操作で評価が異なります。
制限前に確認する一覧
- 外部投稿・アプリ・連携サービスの利用。
- アプリケーションパスワードの所有者と用途。
- 管理画面保存やフォームが使うAPI。
- 監視やキャッシュ、WAFの例外設定。
段階的に制限する
不要な認証情報を失効させ、必要な機能をテストしてから最小限の制限を入れます。設定後は未認証と認証済みの両方を確認します。URLを隠すことより、権限確認・更新・不要連携の整理を優先してください。
連携を棚卸しする具体例
外部投稿アプリ、モバイルアプリ、バックアップサービス、独自システム、フォーム、ブロック編集の利用を一覧にします。各連携について、担当者、認証方式、対象ユーザー、必要権限、不要時の解除方法を記録します。通常のログイン制限を入れただけでAPI経路も同じように守られるとは推測しないでください。
制限後の試験項目
記事の取得・保存、メディア追加、外部投稿、フォーム送信、予約処理などを確認します。認証エラーが出た場合は、API全体を開放せず、対象ルートと権限、トークン、WAFの扱いを調べます。
よくある質問
公開APIに投稿者名が見えたら侵害ですか？
公開設計による場合もあり、露出だけで侵害とは判断できません。必要な公開情報か、認証へ使う識別子の露出を減らせるかを別に評価します。
APIを使っていないと思えば止めてよいですか？
製品が内部で利用している可能性があります。通信と仕様を調べ、検証環境で必要な操作を確認してから制限します。