Cookie 與登入工作階段安全：別讓一次登入變成長期通行證

密碼驗證成功後，風險轉移到工作階段

使用者登入後，網站通常用 Cookie 中的工作階段識別碼辨認後續請求。攻擊者若取得這個值，可能不需要密碼與第二因素就能沿用登入狀態。因此 Session ID 必須是不可預測的隨機值，且伺服器只保存必要的狀態與到期時間。

不要把使用者 ID、權限或敏感資料直接當成可修改的 Cookie 狀態。即使內容經編碼，編碼也不等於防竄改；若採用無狀態 Token，仍需考慮簽章、金鑰輪替、撤銷與外洩後的有效期。

Cookie 屬性要一起設定

• Secure：只透過 HTTPS 傳送。
• HttpOnly：避免一般 JavaScript 讀取工作階段 Cookie。
• SameSite=Lax 或 Strict：降低跨站請求夾帶 Cookie 的機會。
• 精確的 Path 與不設定寬鬆 Domain：縮小可接收範圍。
• __Host- 前綴：在相容條件下強制 Secure、根路徑且無 Domain。

SameSite=None 只應用於確有跨站需求的 Cookie，並且必須搭配 Secure。不要為了單一整合把所有工作階段 Cookie 都放寬。

在權限邊界輪替識別碼

匿名訪客登入成功、啟用更高權限、完成密碼重設或帳號復原後，應產生新的 Session ID，避免 Session Fixation。登出時不只刪除瀏覽器 Cookie，也要讓伺服器端工作階段立即失效。

使用者應能查看並撤銷其他裝置的工作階段。高風險變更如修改密碼、付款資料或第二因素，應要求近期重新驗證，而不是只相信數週前建立的登入狀態。

同時使用閒置與絕對逾時

閒置逾時限制多久沒有活動就要重新登入；絕對逾時限制一個工作階段最長能存在多久。兩者要由伺服器端判斷，不能只靠前端倒數。高權限後台通常需要更短的期限與更嚴格的重新驗證。

所謂「記住我」應使用可撤銷、單次輪替的長期 Token，而不是把一般 Session 延長數月。每次使用後換發新值，若舊值再次出現，就視為可能遭複製並撤銷整個系列。

防止外洩與誤記錄

Session ID 不應出現在網址、Referer、分析事件、錯誤訊息或伺服器日誌。回應也要設定適當的 Cache-Control，避免含個資的登入頁被共享快取保存。跨來源資源政策與 CORS 不應允許任意來源攜帶認證。

HttpOnly 不能阻止 XSS 代替使用者操作，因此仍需修補 XSS、部署 CSP 並保護敏感操作。工作階段安全是一組互相支援的控制，不是勾選幾個 Cookie 屬性就完成。

測試與監控

測試登入前後 Session 是否輪替、登出後舊值是否失效、密碼變更是否撤銷其他工作階段，以及不同瀏覽器 SameSite 行為。確認伺服器拒絕已過期、格式錯誤與無法查到的識別碼。

監控同一 Session 在不合理距離、裝置或短時間內的重複使用，但不要只依 IP 綁定，因為行動網路與企業代理會正常變動。偵測結果應觸發重新驗證或撤銷，而不是把使用者永久鎖死。