1. 題目與使用場景
產品需要讓使用者分享發票、檔案或一次性操作。連結本身攜帶存取能力，服務端不必先識別登入帳戶。面試重點是判斷這種設計何時合理，以及如何面對連結被複製、記錄或轉發的現實風險。
2. 面試官考察點
- 能否區分能力 URL、登入工作階段和 OAuth bearer token 的信任模型。
- 是否把 URL 洩露路徑納入威脅模型：日誌、歷史記錄、分析系統、Referer 和截圖。
- 是否設計短效期、最小權限、單次使用或綁定受眾的令牌。
- 是否提供按連結撤銷、批量撤銷和稽核能力，而不是只能輪換全域金鑰。
W3C 的能力 URL 指南強調，洩露後必須能撤銷原先授予的權限。OWASP 明確建議不要把密碼、API key 或安全令牌放在 URL 中；因此使用能力 URL 必須有清晰的風險邊界和補償控制。
3. 回答前需要釐清的問題
- 資源是公開、低敏感，還是包含個人、財務或合規資料？
- 存取者是否必須登入，連結是否需要跨組織轉發？
- 存取是一次性下載、限定時間窗口，還是長期協作？
- 洩露後需要撤銷單條連結、某個使用者，還是整個資源？
4. 30 秒回答框架
用「適用性—令牌—洩露—撤銷—替代方案」回答：
我只把能力 URL 用於低頻、可稽核且允許持有者存取的資源，並把令牌限制在單一資源和短時間窗口。令牌必須高熵、不可猜測，服務端只存雜湊並記錄建立、使用和撤銷狀態；同時設定 Referrer-Policy: no-referrer，避免把它放入日誌或第三方分析。敏感資源改用登入授權，能力 URL 只作為一次性邀請或下載憑證。
5. 分步驟深入解答
第一步：選擇合適的信任模型
能力 URL 是「持有連結即擁有權限」，不是證明某個帳戶身分。它適合分享低敏感資源、一次性下載或無需註冊的邀請；不適合需要細粒度成員權限、長期稽核或強身分保證的操作。若需要 OAuth bearer token，應優先使用 Authorization 請求標頭；RFC 6750 將 URI 查詢參數列為可用但風險較高的傳遞方式。
第二步：縮小令牌的能力
令牌至少綁定資源 ID、動作和受眾。設定短過期時間、單次使用標記和速率限制；對可轉發場景可增加收件人確認或登入後再兌換。令牌使用加密隨機數產生，資料庫保存雜湊，避免資料庫洩露直接變成可用憑證。
第三步：控制 URL 洩露面
OWASP 提醒，URL 會進入伺服器日誌、瀏覽器歷史和代理記錄。落地頁收到令牌後應儘快透過安全請求交換為短期工作階段，並清理網址列；設定嚴格的 Referer 策略，不把令牌發給第三方資源。郵件、截圖和聊天工具仍可能暴露連結，因此不要把長期高權限放進去。
第四步：實作精確撤銷與稽核
為每個令牌記錄建立者、資源、動作、過期時間、最後使用時間和撤銷時間。撤銷檢查應在每次兌換或下載前執行；單條連結撤銷不能依賴輪換全域金鑰。稽核日誌記錄成功、失敗、重複使用和撤銷原因，幫助識別洩露與濫用。
6. 高品質示範回答
我會先判斷資源敏感度和存取生命週期。公開手冊不需要能力 URL；一份供外部審閱的低敏感發票可以使用，但高敏感財務報表應要求登入和組織權限。
>
對可用場景，我產生至少 128 位元的隨機令牌，並讓它只對應一個資源、一個動作和一個 24 小時窗口。資料庫只保存令牌雜湊、狀態和稽核欄位；兌換成功後立即標記使用，下載介面每次都檢查過期和撤銷狀態。回應設定 Referrer-Policy: no-referrer，兌換後把令牌從網址列移除，頁面不載入會向第三方傳送 Referer 的資源。
>
使用者可以撤銷單條連結，管理員可以按資源批量撤銷；撤銷和重複使用都會寫入稽核日誌。若業務後來需要長期協作，我會遷移到登入授權和成員權限，而不是把能力 URL 延長為永久 bearer token。這樣既保留分享便利，也把洩露影響限制在單一資源和有限時間內。
7. 常見錯誤
- 把「連結很長」當成安全性，忽略日誌、歷史記錄和轉發洩露。
- 使用可預測的資源 ID 或自增 token。
- 把長期、高權限 bearer token 放在查詢參數中。
- 只有全域金鑰輪換，沒有單條連結撤銷。
- 令牌兌換後仍讓它留在網址列，並載入第三方圖片或分析腳本。
8. 追問及應對
追問一：為什麼資料庫只保存令牌雜湊？
令牌是持有者憑證，資料庫讀取權限一旦洩露，明文令牌會立即可用。保存雜湊後，服務端可以對提交值做同樣雜湊比對，降低靜態資料洩露影響。
追問二：單次使用會不會導致使用者重新整理失敗？
把一次性令牌用於兌換短期工作階段，頁面重新整理使用工作階段而不是重複兌換原連結；若兌換成功但回應遺失，可提供受限的冪等兌換結果，而不重新開放長期能力。
追問三：何時應完全放棄能力 URL？
當資源高敏感、需要持續成員管理、必須證明存取者身分，或組織要求集中撤銷與稽核時，使用登入授權和服務端權限模型更合適。