題目與適用場景
你的認證 API 同時監聽 HTTP 與 HTTPS，HTTP 請求會 301 到 HTTPS。請說明這個設計的風險、伺服器與客戶端應如何改造，以及如何相容舊客戶端。題目基於 IETF HTTPAPI 工作組 2026 年 5 月更新的 Internet-Draft；該文件仍是 work in progress，不能當作最終 RFC。
面試官考察點
- 能否指出重新導向發生前憑據已經經過明文網路。
- 能否組合 HSTS、HTTPS DNS 記錄、連接阻斷與 Secure Cookie 等控制。
- 能否處理共享主機、舊客戶端、代理與憑據撤銷等現實限制。
- 能否用可驗證指標證明風險下降，而不是只說「全站 HTTPS」。
回答前需要釐清的問題
- HTTP 與 HTTPS 是否使用同一主機名與同一監聽入口？
- 憑據是 Bearer token、Cookie、API key，還是請求簽章？
- 是否有無法立即升級的舊客戶端、企業代理或內網呼叫？
- HTTP 入口是否也承載不需認證的資源？
- 是否已有 HSTS、HTTPS DNS 記錄、金鑰輪換與稽核日誌？
30 秒回答框架
重新導向無法挽回已發出的明文憑據；被動監聽者可能複製 Bearer token 或 Cookie。認證 API 應優先讓 HTTP 入口在建立連線前失敗，使用 HTTPS DNS 記錄與 HSTS 降低首次及後續誤配；Cookie 設定 Secure，客戶端預設拒絕不安全連線。無法立即阻斷時，對帶憑據的明文請求統一回傳 403，並按策略撤銷可能洩露的憑據，避免依憑據真假產生不同回應。遷移期間保留明確指標、灰度與回滾窗口。
分步驟深入解答
1. 說明重新導向的洩露時點
客戶端先送出 HTTP 請求，可能已包含 Authorization、Cookie 或 API key；伺服器之後回傳 301，不能擦除網路中已暴露的內容。攻擊者可重放 Bearer token 或 Cookie。即使最終 HTTPS 請求成功，應用也可能讓錯誤配置長期不被發現。
2. 設計伺服器入口
對認證端點，優先關閉公網明文監聽，或讓 80 埠只服務明確的網路來源。不要把 301 當成安全控制。若共享主機必須保留 HTTP，閘道要識別帶憑據的請求並統一回傳 403，不透露憑據是否有效。
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0回應行為不能因憑據有效或無效而不同，否則攻擊者可藉此測試竊取的憑據。
3. 讓客戶端減少首次誤配
HTTPS DNS 記錄可在連線階段提示客戶端使用安全連線；HSTS 讓成功建立 HTTPS 後的後續連線自動升級。兩者都不是萬能：HSTS 依賴此前成功連線與客戶端實作，DNS 記錄也可能被阻斷。因此應在 SDK、CLI 與設定校驗中預設拒絕 http，並在日誌中提示可操作的修復路徑。
4. 限制憑據的使用範圍
Cookie 應帶 Secure 屬性；令牌應限制在安全上下文，必要時採用綁定到請求或連線的簽章機制。不同憑據不能套用同一撤銷策略：直接可重放的 API key、Bearer token 與 Cookie 通常要立即撤銷，只有不可偽造請求的派生簽章才可能保留。
5. 處理已洩露的憑據
收到帶憑據的明文請求後，應將憑據視為潛在洩露。伺服器可以先統一 403，再在安全連線上的下一次使用回傳「憑據已撤銷」的可診斷錯誤。撤銷動作要寫入稽核日誌，通知持有者輪換，並避免把敏感值寫入日誌、快取或錯誤回應。
6. 相容與遷移
先在 SDK 與測試環境拒絕 HTTP，再對新租戶預設關閉明文入口，最後分批遷移舊租戶。為必須使用舊代理的客戶提供短期專用過渡入口，但不得接收認證憑據；設定截止日期、監控 403 比例與輪換完成率。若共享主機的公開資源仍需 HTTP，應把認證 API 拆到獨立主機名或閘道策略。
7. 驗證安全性
檢查網路抓包中不存在 Authorization、Cookie 或 API key；驗證 HTTP 入口的連線失敗與 403 行為，測試 HSTS 快取、首次存取、代理、重試與回滾。指標包括明文請求數、帶憑據的明文請求數、自動撤銷數量、403 誤報率、舊客戶端占比與遷移完成率。
高品質示範回答
我不會把 301 重新導向當作認證 API 的安全方案，因為憑據在重新導向前已經走過明文網路。被動監聽者可以複製 Bearer token 或 Cookie，成功的 HTTPS 重試反而會掩蓋客戶端設定錯誤。
伺服器先關閉認證端點的公網 HTTP 監聽；如果共享主機暫時不能關閉，閘道對所有帶憑據的 HTTP 請求統一回傳 403，不根據憑據真假改變回應，並把憑據標為潛在洩露。對可重放的 token、API key 與 Cookie 執行撤銷和輪換。客戶端 SDK、CLI 與設定校驗預設拒絕 http，伺服器同時使用 HTTPS DNS 記錄與 HSTS 降低首次及後續誤配，Cookie 設定 Secure。
遷移按新租戶、測試環境、舊租戶分批進行，給企業代理一個不接收憑據的短期過渡窗口。驗收看抓包、明文請求數、帶憑據明文請求數、撤銷與輪換完成率、403 誤報率與舊客戶端占比。這樣既解決洩露路徑，也給出可回滾的遷移計畫；IETF 文件仍是草案，具體部署承諾應保持可調整。
常見錯誤
- 認為 HTTPS 重新導向可以保護已發送的 Authorization 或 Cookie。
- 只設定 HSTS，卻忽略首次連線、舊客戶端與非瀏覽器 SDK。
- 對有效和無效憑據回傳不同的明文回應，洩露可測試訊號。
- 把所有憑據當成同一種，忽略簽章派生值與可重放 token 的差異。
- 直接刪除 HTTP 入口，卻沒有遷移、監控、撤銷與回滾計畫。
追問及應對
如果 HTTP 入口還服務公開資源怎麼辦？
把認證 API 遷到獨立主機名，或在閘道按路徑與憑據標頭隔離。公開資源可有自己的重新導向策略，認證端點必須拒絕帶憑據的明文請求。
HSTS 能解決首次存取嗎？
不能完全解決。HSTS 需要客戶端先成功建立 HTTPS 並持久化策略；因此 SDK、設定校驗、HTTPS DNS 記錄與部署檢查仍需共同覆蓋首次連線。
什麼時候撤銷憑據？
只要憑據出現在明文請求中，就按潛在洩露處理。可重放 token、API key 與 Cookie 應撤銷並輪換；僅暴露不可偽造的派生簽章時，依威脅模型決定是否撤銷。
如何避免升級造成大面積中斷？
先在測試與新租戶啟用拒絕，觀測舊客戶端與 403 誤報，再分批遷移。保留不接收憑據的短期過渡入口與明確截止日期，完成後刪除過渡路徑。