先日、WordPress 6.9 から使えるようになった Abilities API を活用して、業務効率化のためのツールを開発しました。
社内のある作業を API 化し、外部のツールや Claude、Gemini、ChatGPT などの AI エージェントから直接呼び出せるようにする、というものです。
外部から呼び出せるようにする際の仕組み
作った機能を外部のシステムから呼び出せるようにするには、「これを実行してよいアカウントである」ということを証明する仕組みが必要です。
WordPress には標準機能として「アプリケーションパスワード」というものが用意されています。
ユーザーのプロフィール画面から専用のパスワードを発行し、それを外部システムに使わせる、という仕組みです。
アプリケーションパスワードを発行するアカウントの権限に注意
アプリケーションパスワードは、識別しやすいように名前をつけることができます。一見すると「この API 専用（社内業務用）で利用するパスワード」のように思えますよね。
しかし実際には、発行したアカウントが持つ権限を、そのまま引き継ぐ性質があります。
たとえば管理者権限を持つアカウントでアプリケーションパスワードを発行した場合「特定の機能専用」のつもりで名前を付けていても、実際には次のような操作ができてしまいます。
- 新しい管理者アカウントを作成する
- 既存ユーザーのパスワードを変更する(アカウントの乗っ取り)
- 別のユーザーに、さらに別のアプリケーションパスワードを発行する(裏口を増やす)
- プラグインをインストール・有効化する
- サイトの設定(新規登録者に与えるロールなど)を書き換える
このように「必要以上に操作ができてしまう状態」は、ユーザー名とアプリケーションパスワードが誰かに漏れてしまった場合、悪用されるリスクが甚大なので、極力作らない方がいいです。そういう意味では注意が必要です。
何もわかっていない管理者権限を持つユーザーが上記のような状態を簡単に作らないよう、アプリケーションパスワードの発行を無効化できるセキュリティ強化関係のプラグインや、プログラムによる制御方法も存在します。
外部連携の機能を提供する際は、この前提を踏まえた上で、自分たちで権限の設計をする必要があります。
情報が漏れてしまった場合を想定しよう
Abilities API を呼び出すために必要なユーザー名やアプリケーションパスワードなどの情報は、どんなに頑張っても「絶対に漏れない」という状況を作ることはできません（可能な限り漏れないよう、近づけることはできます）。
それは WordPress の脆弱性をついた攻撃を経由することもあれば、次のような日常的な運用の中から経由して漏れる可能性があります。
ケース①：連携先システム自体が侵害されたとき
情報を保存している外部システムやサーバーが、何らかの理由で侵入されたとき
ケース②：ログにそのまま記録されてしまう
通信の記録を残す際、パスワードを含むヘッダーをマスクし忘れ、ログを閲覧できる第三者の目に触れてしまったとき
ケース③：ソースコードへの書き込みミス
開発中に設定ファイルに直接アカウント情報を書き込み、そのまま GitHub などで Public のままソースコードをアップロードしてしまう（たびたびニュースになっていますよね）
ケース④：人の手を介したやり取りで発生
チャットやメールで一時的に情報を共有したまま放置され、担当者の変更後もアクセス権の見直しが行われない場合
適切な権限設計を施す
万が一情報が漏れた場合、被害を最小限に抑えるため、当社では、次の手順で権限設計を行っています。
こうしておくことで、管理者権限を持つユーザーですら呼び出すことはできませんし、万が一情報が漏れた場合でも、影響範囲を「この API を呼び出せること」だけに限定できます。
つまり、「必要以上の操作ができないようにしておこう」ってことですね。
まとめ
アプリケーションパスワードは、発行したユーザーが持つ権限をそのまま引き継いでしまう、という点は押さえておく必要があります。また、WordPress の脆弱性を突いた攻撃を受けた場合や、日々の運用の中でユーザー名やアプリケーションパスワードが漏れる可能性は完全には否定できません。
そのため、漏れる確率を可能な限り下げるような施策は当然として、もし漏れた場合でも、その被害をどれだけ小さくできるかを想定し「漏れない前提」の権限設計をしないことが重要だと考えます。
