HTTP 307 Temporary Redirect
本篇文章與將外網網址指向內網環境這篇可以一起閱讀。
HTTP 307 是一種 3xx 類狀態碼（Redirection Class），代表伺服器要求用戶端前往另一個位置取得資源。
完整名稱為：
307 Temporary Redirect – 暫時重新導向
技術定義
當伺服器希望將請求暫時導向另一個 URI 時使用此回應。
用戶端應使用相同的 HTTP 方法（例如 POST 不可改成 GET），並重新送出請求到 Location 標頭指定的 URI。
範例
1 | |
這表示：
伺服器暫時把 /login 請求導向另一個網址；
用戶端必須原封不動地重送同樣的請求（包括方法與 body）。
- 與 301、302、308 的差別
| 狀態碼 | 說明 | 是否改變請求方法 | 永久性 |
|---|---|---|---|
| 301 | 永久重導 | 可能改成 GET | 永久 |
| 302 | 暫時重導（舊規範) | 可能改成 GET | 暫時 |
| 307 | 暫時重導（新規範） | 保留原方法 | 暫時 |
| 308 | 永久重導（新規範） | 保留原方法 | 永久 |
換句話說，307 是不改變請求內容的 302。
實務中常見的 307 案例
- HTTPS 強制導向
許多網站會用 307 來強制 HTTP 請求改走 HTTPS：
1 | |
這樣能保留使用者的原始請求方法（例如表單 POST），而不會被轉成 GET。
- 負載平衡或反向代理
部分企業會讓負載平衡器或 WAF 在系統維護時回應 307，
把流量臨時導向到備援伺服器：
1 | |
但這樣在使用者來說有可能會出現重導向過多而無法連線的狀態。
- OAuth / SSO 登入流程
SSO（單一登入）或 OAuth 授權過程中，常會看到連續的 302、307、308，
例如：
1 | |
這些導向不是錯誤，而是驗證流程的一部分。
- 惡意重導或釣魚
有些攻擊者會利用 307 來隱藏跳轉：
攻擊者控制一個中繼站回應 307；
將使用者導向惡意網站；
因為方法不變、參數保留，容易誘導到假登入頁面。
這在釣魚攻擊與惡意流量分析中曾被觀察到，例如：
某些惡意廣告平台會使用 307 階段性轉導；
駭客利用 Cloudflare Worker 模擬合法導向鏈。
307 在資安上的應用與風險
| 應用情境 | 可能風險 |
|---|---|
| HTTPS 強制導向 | 若實作錯誤可能導致明文流量短暫外洩 |
| 負載平衡轉導 | 攻擊者可偽造 307 導向惡意主機 |
| OAuth 驗證流程 | 攻擊者可竄改 redirect_uri 造成Open Redirect漏洞 |
| 臨時維護轉址 | 若未設存取控管，可能意外暴露內部位址 |
曾出現 307 的實際事件
案例 1：GitHub Pages HTTPS 轉導問題
早期 GitHub Pages（2020 年前）在 HTTP → HTTPS 轉導時使用 307。
部分舊版瀏覽器誤判導向無限循環，造成頁面載入錯誤。
這個問題後來改為使用 301/302 處理。
案例 2：Google OAuth Redirect 漏洞（CVE-2020-26882）
研究人員發現某些 OAuth 實作使用 307 回傳導向時，
若未妥善驗證 redirect_uri，
攻擊者能利用這個暫時導向將授權碼外洩到第三方網站。
雖然這不是 307 本身的漏洞，但導向機制是觸發點。
案例 3：Cloudflare Workers Redirect Chain
安全研究人員在分析 Cloudflare Worker 的 URL rewrite 行為時，
觀察到攻擊者利用 307 與 308 組合製造「多層跳轉鏈」，
用來繞過惡意網域偵測系統。
這是現代釣魚網站常見的隱蔽技巧。
307 是「暫時重導且不改變請求方法」的狀態碼。
常見於 HTTPS 強制轉導、代理轉址、SSO/OAuth 流程中。
並非錯誤，但要留意是否為惡意導向或配置錯誤。
在弱掃中若遇到 307，可透過 Custom Host 或手動追蹤最終導向，確保掃描內容正確。