把 WordPress 串接到 Zapier、n8n 這類自動化平台，或是讓某個 AI 助手、行動 App 讀寫你的後台內容時，對方十之八九會先要求你輸入帳號密碼。這時候多數人會遲疑，把平常登入後台用的那組密碼原封不動交出去，真的安全嗎？
先別急著回答。WordPress 其實早就內建一套解法，叫做 WordPress Application Passwords：它讓每一個外部整合各自拿到一組專屬密碼，你可以個別撤銷、彼此互不影響，而且這組密碼完全沒辦法拿來登入後台，這正是最小權限原則的具體實作。
接下來會依序拆開講，它跟一般登入密碼差在哪、怎麼建立與驗證，最後把管理與踩雷的地方一次說清楚。先從它跟你平常用的密碼有什麼不同講起。
Application Passwords 是什麼？和登入密碼有什麼不同？
Application Passwords 是綁定在特定使用者帳號底下的一組密碼，專門給程式化存取用。REST API、XML-RPC 這類 API 請求要驗證身分時，認的是這一組密碼，不是你平常登入後台用的那一組主密碼，兩者是完全獨立的兩套系統。這套機制以前得靠外掛才有，WordPress 5.6 版（2020 年 12 月釋出）之後直接內建進核心，不用再另外安裝外掛。
它最關鍵的限制，是這組密碼完全沒辦法拿去 wp-login.php 登入後台。WordPress 只在驗證 API 請求的 Basic Authentication 這個管道認得它，介面登入那一關完全不吃這組密碼。這正是它安全的根本原因，不是靠使用者自己小心保管，而是機制設計上就把它鎖死在只能做 API 驗證這一件事，拿去做別的一律失效。
密碼本身的格式也刻意設計成一次性顯示、隨機組成。它總共 24 個字元，只由大小寫英文字母與數字組成，不含任何特殊符號，由 WordPress 系統自動產生，換算下來熵值超過 142 位元，用暴力猜測的方式幾乎不可能破解。介面上會把它分段顯示成幾組方便閱讀，但這組明碼只有建立當下才看得到，之後系統只留一份雜湊值，連使用者自己都沒辦法再回頭看到原始密碼。
換句話說，這組密碼扮演的角色更像一張核發給特定程式的識別證，而不是你的第二組登入密碼。
共用登入密碼的風險與最小權限原則
如果每一個要串接的外部服務都得輸入同一組後台登入密碼，風險會直接疊加在同一個點上。只要其中一個服務外洩或被入侵，等於整個後台一起淪陷；而且要收回權限沒有捷徑，只能整組改密碼，再回頭通知所有已經串接的服務重新設定，牽一髮動全身。
Application Passwords 把這個單點風險拆開。同一個使用者帳號可以同時發出好幾組密碼，一個外部服務對應一組，彼此互不影響，撤銷其中一組不會動到其他仍在正常運作的服務，也不需要驚動任何無關的整合。
這背後其實是最小權限原則在運作，給外部服務的存取權限，應該只給它完成任務所需要的最小範圍，而不是預設用管理員帳號一次授權到底。這條原則接下來會在「自動化帳號」那一節具體落地成操作步驟，先把它記在心裡。
怎麼建立一組 Application Password？
在談最小權限怎麼落實之前，你得先有一組真正的 Application Password 可以用。建立的路徑只有兩種，一種是任何人都用得到的手動操作，一種是給開發者或自動化流程用的程式化建立。至於這一步該用哪個帳號登入來建立，牽涉到最小權限原則，留到後面「自動化帳號」那一節再深談，這裡先把怎麼生出一組密碼這個動作講完整。
在後台個人資料頁手動建立 Application Password
手動建立的路徑很直接。先登入 WordPress 後台，進入使用者，點開個人資料頁面（如果是以管理員身分要幫別人建立，也可以直接編輯對方的個人資料）；往下捲動，會看到「Application Passwords」這個區塊。在這裡輸入一個好記的名稱，例如「某某自動化流程」或「某某 App」，方便自己日後一眼認出這組密碼是給誰用的，接著點擊新增。系統會立刻顯示出這組密碼，務必當下就複製起來、存到安全的地方，因為離開這個畫面之後就再也看不到明碼了。
這裡輸入的名稱只是給自己辨識用，不會影響密碼本身能存取的範圍，權限範圍是由登入的這個使用者帳號本身的角色決定。
用 REST API 或 WP-CLI 自動建立 Application Password
部署腳本或 CI/CD 流程需要自動產生密碼時，手動點幾下顯然不夠用。REST API 本身就有專屬的端點，可以用來建立、查詢、撤銷 Application Password，回傳的紀錄含有 uuid、app_id、name、password、created、last_used、last_ip 這些欄位，足以在自動化流程裡完整追蹤每一組密碼的狀態。有 SSH 存取權限的話，WP-CLI 也提供對應的指令，能直接建立、列出、刪除密碼，不用透過瀏覽器介面操作。
wp user application-password create 12 "自動化部署腳本"Code language: Bash (bash)這些方式讓 Application Passwords 可以整合進整套自動化部署流程，而不只是手動點幾下的操作而已。
怎麼用 Application Password 驗證 API 請求？
拿到密碼之後，下一步是搞懂怎麼真的送出一個帶驗證的 API 請求。Application Passwords 走的是 HTTP Basic Authentication，也就是 RFC 7617 定義的那套驗證方式，歷史悠久，幾乎每一種程式語言、每一支 API 除錯工具都原生支援。做法是把「使用者名稱：密碼」這一整串文字做 Base64 編碼，再放進 Authorization 標頭裡送出去。這裡的使用者名稱要用 WordPress 的登入帳號，不是註冊時留的電子郵件地址。
用 curl 或 API 除錯工具快速測試驗證是否成功
最小可行的測試方式，是用一行 curl 指令帶上帳號密碼，打向 REST API 的使用者端點，確認驗證有沒有成功。
curl --user "使用者名稱:應用程式密碼" https://example.com/wp-json/wp/v2/users/meCode language: Bash (bash)驗證成功的話，會回傳目前這個使用者的資料；帳號密碼有誤的話，會得到一個驗證失敗的錯誤訊息。
這裡有一件事一定要顧到，連線一定要走 HTTPS。Basic Authentication 本質上只是把帳號密碼做編碼，不是加密，少了 HTTPS 等於用明碼在網路上直接傳送密碼，任何攔截封包的人都看得懂。
串接自動化工具與外部服務
會用到 Application Password 的，不是只有開發者手動測試這種場合。常見的情境包括讓 Zapier、n8n 這類自動化平台讀寫 WordPress 內容、讓部署腳本在發布流程中呼叫 REST API，或是讓行動 App、第三方前端這類 headless 架構，對後台資料做認證存取。不少自動化平台的 WordPress 連接模組，設定畫面上要你填的欄位就是網站網址、使用者名稱和 Application Password，而不是完整登入資訊。這些情境的共通點都一樣，對方拿到的是專屬於它的一組密碼，不是你本人的登入密碼。
自動化用的帳號，權限要比你想的更小
上面這些串接情境都指向同一個問題，這組專屬密碼該用哪個帳號產生。最小權限原則落到實際操作，重點在帳號的選擇，而不是密碼本身。不要用管理員帳號產生的 Application Password，去授權一個只需要讀文章、或只需要發佈文章的服務。比較穩妥的做法是另外建立一個權限受限的使用者，例如編輯或作者層級的角色，再用這個受限的帳號去產生給該服務用的密碼。
這樣安排的好處很直接，即使這組密碼外洩，攻擊者能做的事也被侷限在那個角色的權限範圍內，不會一次拿到管理員層級的完整存取權。
WordPress 核心開發團隊自己也把依應用程式限縮權限範圍列為值得繼續強化的方向，說明這不是這篇文章自己延伸出來的建議，而是這套機制在設計之初就有的精神，只是目前還得靠使用者自己在帳號層級把它落實出來。
已核發的密碼，怎麼盤點與撤銷？
帳號選對了，還要有個機制持續確認這些密碼有沒有變成風險。個人資料頁的 Application Passwords 區塊，本身就是一份可以拿來盤點的清單。裡面列出每一組密碼的名稱、建立時間、最後使用時間，以及最後使用的 IP 位址，這些欄位就是用來做例行盤點的依據。發現某一組密碼很久沒被使用，或是最後使用的 IP 位址看起來很陌生，就是該撤銷它的信號。
撤銷動作只針對單一一組密碼進行，不會影響其他仍在使用中的服務，可以放心單獨處理，不必擔心牽連。
把 Application Passwords 當成機密資料來看待，是比較穩妥的操作紀律，一個服務對應一組密碼，不再使用的立刻撤銷，懷疑外洩的話就撤銷重發，不要抱著僥倖心態繼續沿用。
為什麼帶著正確密碼，API 還是回傳 401？
密碼盤點做得再勤，還是可能踩到這種狀況，明明確定密碼是對的，API 卻還是不放行，原因通常出在幾個常被忽略的環節，不是密碼本身壞了。依序檢查以下四個地方，八成能抓到問題所在：
- 網站是不是真的跑在 HTTPS 上。Application Passwords 預設只在 HTTPS 環境下才能使用，非加密連線會直接被擋下來。
- 登入用的是不是 WordPress 的使用者名稱，而不是註冊信箱，這兩者在這裡不能互換。
- 密碼有沒有複製完整，24 碼分段顯示，帶不帶中間的空格都可以，但只要漏掉一兩個字元就會驗證失敗。
- 以上三項都確認沒問題卻還是回傳 401，才輪到考慮是不是主機層級把 Authorization 標頭整個過濾掉了。這種情況在部分共用主機環境並不少見，可能需要調整伺服器設定，或聯絡主機客服確認標頭有沒有被正確轉送進來。
AI 代理要串接 WordPress，用的也是同一套密碼機制
排查完常見的人為疏失，還有一種愈來愈常見的串接對象值得特別說一次，那就是 AI 代理。2026 年，WordPress 官方推出 MCP Adapter，實作的是 Model Context Protocol，讓 Claude、Cursor 這類 AI 工具能夠發現並呼叫 WordPress 的功能。在它對外公開的 HTTP 連線方式裡，預設的驗證方式用的正是 Application Passwords。
換句話說，原本用來擋掉把登入密碼共用給自動化工具這個風險的機制，現在直接套用在授權 AI 代理存取自己網站這件事情上。密碼專屬、可以個別撤銷、也沒辦法拿去登入後台，同一套邏輯完全適用，不需要另外學一套新東西。
實務上的做法也一致，如果要讓 AI 工具讀寫網站內容，一樣得先為它建立一個專屬的、權限受限的帳號，再用那個帳號產生 Application Password 給 AI 工具用，而不是圖方便直接把管理員帳號的密碼交出去。
不管你串接的是自動化工具、行動 App，還是 AI 代理，同一個判斷準則都成立。每多授權一個外部服務存取，就該多開一組專屬的、權限剛好夠用的 Application Password，而不是一次又一次交出同一組登入密碼。
隨著 WordPress 把 AI 串接也建立在這套機制之上，正確管理 Application Passwords 只會越來越重要，不是設定一次就能一勞永逸的事。