2026.11.05

替 WordPress 自動化整合建立專用應用程式密碼，並安全驗證與撤銷

當備份程式、排程工作或外部服務需要透過 REST API 存取 WordPress，應為該整合建立專用的應用程式密碼，而不是交付日常登入密碼。這類憑證方便個別停用；但權限仍承襲所屬 WordPress 使用者的權限，不能把它當成可自行細分權限的帳號。建立前，先確認整合需要哪個使用者與操作範圍。

建立前先確認 HTTPS 與帳號權限

先確認網站使用 HTTPS，並確認整合服務支援 WordPress REST API 的應用程式密碼驗證。再檢查要使用的 WordPress 帳號：憑證會繼承該帳號的權限，因此不要為了方便，把管理員憑證交給只需讀取文章的整合。若要了解登入帳號的其他防護方式，可參考 BarryBlogs 的WordPress 雙重驗證設定教學。

逐一為整合建立憑證

以該整合所屬的 WordPress 使用者登入後台，開啟「使用者」中的個人資料頁面。
找到「應用程式密碼」區域，輸入容易辨認的名稱，例如「每日備份－正式站」，然後新增密碼。名稱要能對應實際服務或用途，方便日後盤點。
產生後立即將密碼放入核准的密碼管理工具，並在整合服務端設定 WordPress 使用者名稱、應用程式密碼與 HTTPS 網址。密碼只會在建立時顯示一次；離開畫面後無法再查看，遺失時應建立新憑證。
不要把密碼貼在工單、聊天訊息、截圖、程式碼版本庫或共用試算表，也不要放進會被記錄的網址或除錯輸出。若服務支援遮蔽欄位或秘密管理功能，使用該功能。

用實際 API 請求確認可用

儲存設定後，從整合服務執行一次它預計使用的操作，例如讀取文章清單或送出測試資料，並確認服務收到預期回應。若要獨立檢查，可透過受信任的 API 用戶端，以 HTTPS 呼叫網站 REST API，使用該使用者名稱與應用程式密碼驗證；先選不會修改內容的讀取端點，確認回應狀態與資料，再測試必要的寫入功能。只要驗證登入成功，不代表整合所需的每項操作都成功，仍應核對服務端的執行紀錄及實際結果。避免在共用終端機輸入會被歷史紀錄保存的秘密。

替換或停用時，先驗證新設定

輪替憑證、移轉服務或處理離職帳號時，先在整合端換上新憑證，執行代表性操作並確認排程或工作流程成功。確認新憑證已接手後，回到原使用者的應用程式密碼清單，依名稱撤銷舊憑證；離職人員則應一併檢查帳號、其他整合及服務持有者。若先撤銷舊憑證，仍依賴它的工作會立即失敗。撤銷後再次執行工作或檢查連線錯誤，確認舊憑證已無法使用。

限制、安全與回復方式

應用程式密碼是 API 憑證，不是後台網頁登入密碼，不能用它登入 WordPress 後台；而且它承襲使用者權限，不提供獨立的細分權限。若憑證疑似外洩，立即撤銷並檢視相關操作紀錄，再為仍需使用的整合建立新憑證、更新設定與驗證。若更新後整合故障，先確認網址、使用者名稱、憑證是否貼錯，以及服務是否支援此驗證方式；需要恢復服務時，建立新憑證並重新設定，不要嘗試找回已不再顯示的舊密碼。

詳細欄位與使用方式請以 WordPress 官方的應用程式密碼說明為準。定期盤點憑證名稱、用途與負責人，能在整合停用或人員異動時迅速撤銷正確的項目。