WordPressをn8nや独自ツールから操作するとき、認証情報をどこへ保存するかは本文生成より重要な設計になります。Application PasswordはWordPress 5.6から使える標準機能で、2026年にWordPress公式のSecurity Handbookでも管理・ローテーション・トラブルシューティングが整理されています。
名前に「Password」とありますが、wp-login.phpへ入るための通常パスワードとは用途が違います。APIやスクリプトなどプログラムからのアクセス用で、作成時に一度だけ表示され、WordPress側ではハッシュ化して保存されます。
通常パスワード・Application Password・2FAは役割が違う
| 項目 | 通常ログインパスワード | Application Password | 2FA |
|---|---|---|---|
| 主用途 | 人がwp-adminへログイン | アプリ/スクリプトのAPI認証 | 人のログインを追加要素で保護 |
| 連携単位で失効 | 不可 | 可能 | 対象外 |
| wp-login.phpで使用 | 使用する | 使用しない | 通常ログインと組み合わせる |
| 漏えい時の影響 | アカウント全体に影響しやすい | 対象credentialだけ止められる | 単独ではAPI credentialの代替ではない |
「2FAを入れているからAPI連携も安全」とは限りません。自動化ツールが通常パスワードを保持していれば、その秘密情報自体の管理問題が残ります。人のログインは強いパスワード＋2FA、外部API連携はApplication Passwordなど連携向けの認証手段に分けると管理しやすくなります。
安全な発行・分離・権限設計
発行はユーザープロフィールから行い、名前で用途を判別できるようにする
WordPress管理画面のユーザープロフィールにはApplication Passwordsの欄があり、連携名を付けて新しいcredentialを発行できます。表示された値は作成時にしか確認できないため、その場でパスワードマネージャーやsecret管理先へ保存します。
名前は「API」「test」のように曖昧にせず、「site-a-production」「content-draft-automation」のように、用途・環境・対象を後から識別できる形にします。半年後に一覧を見たとき「このcredentialを消してよいか」が判断できない名前は、インシデント対応を遅らせます。
1つを使い回さず「1連携1credential」にする
複数のツールで同じApplication Passwordを使い回すと、どこから漏れたのか追跡しにくくなります。連携ごとに分ければ、n8nだけ停止、検証用スクリプトだけ停止、といった個別失効ができます。WordPress公式も、integration/appごとに作成して再利用しない運用を推奨しています。
複数サイトでも同様です。1つの秘密情報を全サイトへ横展開するより、サイト×連携でcredentialを分けた方が影響範囲を小さくできます。管理数は増えますが、secret managerや台帳で「サイト・WordPressユーザー・連携名・作成日・更新日」を管理すれば、漏えい時の切り分けが早くなります。
HTTPSは必須と考える
Application Passwordを使うREST API認証ではBasic Auth形式でcredentialを送るため、通信路の暗号化が前提です。WordPress公式はHTTPSを利用するよう明確に案内しています。HTTPの検証環境へ本番credentialをそのまま流す運用は避けます。
「HTTPS表示できる」だけでなく、外部ツールがアクセスするURLもhttps://になっているかを確認します。リバースプロキシやCloudflareを使っている環境では、WordPress側がHTTPSとして正しく認識しているかも確認対象です。
権限はApplication Passwordではなく紐づくWordPressユーザーにも依存する
Application Passwordは新しい管理者権限を作るものではありません。credentialは特定のWordPressユーザーに紐づき、そのユーザーが持つcapabilityの範囲でAPI操作します。投稿の下書きだけを行う連携に、何でもできる管理者credentialを使う必要があるかは検討すべきです。
一方、必要な操作に対して権限を下げすぎると403が続きます。重要なのは「最小権限」という言葉だけで終わらず、実際に必要なendpointと操作を列挙して、それに必要なWordPress role/capabilityを検証することです。
last used / last IPを「使われているcredentialか」の判断材料にする
WordPressではApplication Passwordごとに使用情報を確認できます。公式Handbookではlast used timeやlast IPといったmetadataが案内されています。長期間使っていないcredential、想定外のIPから使われたcredentialは、残し続ける理由を見直すきっかけになります。
ただしIPだけで攻撃と断定はできません。クラウドサービスやプロキシ経由では送信元が変わる場合があります。連携側の実行履歴、時刻、対象endpointと合わせて「その利用は自分のジョブか」を確認します。
ローテーションは「新規発行→切替確認→旧credential失効」の順
- 同じ用途で新しいApplication Passwordを発行する
- 新credentialを連携先のsecretへ登録する
- 読み取りなど低リスク操作で認証成功を確認する
- 本来の処理が正常に動くことを確認する
- 旧credentialをWordPress側で失効する
- 台帳の更新日・失効日を更新する
旧credentialを先に消すと、切替に失敗した瞬間に自動化が止まります。反対に、新旧を長期間併存させると漏えい面が広がります。切替作業中だけ重複させ、正常性を確認したら旧credentialを消すのが扱いやすい流れです。
漏えいを疑ったら「通常パスワード変更」より対象credentialの失効を先に判断する
Application Passwordが漏れた可能性がある場合、そのcredentialを個別に失効できます。連携ごとに分離していれば、他の自動化まで全部止めずに対象だけ遮断できます。その後、アクセスログ・実行ログ・WordPressの更新履歴を確認し、意図しない投稿変更やメディア作成がないか調べます。
通常ログインパスワードと同じ値を使っているわけではないため、Application Passwordの漏えい＝通常パスワードも漏えい、と即断する必要はありません。ただし端末やsecret保管先そのものが侵害された疑いがあるなら、他のcredentialも含めて広く確認します。
401/403で詰まったときの確認順
| 症状 | 確認ポイント |
|---|---|
| Application Password欄がない | HTTPS、security plugin、利用可否filter、WordPress設定 |
| 401になる | ユーザー名、Application Password、Authorization headerが送信されているか |
| 403になる | 対象ユーザーのrole/capability、endpoint側permission |
| ローカルでは動くが本番で失敗 | proxy/FastCGI等でAuthorization headerが落ちていないか |
| 突然動かなくなった | credential失効、ユーザー権限変更、security設定変更 |
認証エラーを直すために通常パスワードをコードへ書き込むのは避けます。まずHTTPクライアントがBasic Authを送っているか、サーバー/プロキシがAuthorization headerをWordPressまで渡しているか、対象ユーザーに必要権限があるかを順に確認します。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://developer.wordpress.org/advanced-administration/security/application-passwords/
- https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
- https://developer.wordpress.org/rest-api/reference/application-passwords/
コメント