先界定攻擊面，而不是只相信內網
工作階段劫持的核心，是攻擊者取得或濫用一個仍然有效的工作階段憑證。來源可能是跨站指令碼、惡意瀏覽器外掛、記錄到日誌的 Cookie、共用電腦未登出、反向代理設定錯誤，或使用者在釣魚頁面完成登入。即使系統只開放給公司網路或 VPN，端點裝置、第三方 SaaS、遠端辦公網路與整合 API 仍會擴大信任邊界。
工程團隊應先盤點哪些系統使用瀏覽器 Cookie、哪些透過 SSO、哪些帳號擁有核准、匯出、權限管理或財務操作能力。一般查詢頁面、管理後台與高權限工具不一定適合共用相同的工作階段政策。風險評估的重點不是系統是否「內部使用」，而是憑證外洩後能做什麼、能維持多久，以及能否快速撤銷。
把 Cookie 當成高價值憑證管理
工作階段 Cookie 應由伺服器產生足夠隨機且不可預測的識別碼，實際權限與狀態保留在伺服器端。Cookie 至少應設定 Secure 與 HttpOnly，並依登入流程選擇 SameSite=Lax 或 SameSite=Strict。Strict 的隔離較強，但可能中斷從郵件、企業入口網站或身分提供者返回系統的流程；Lax 通常較容易相容，但仍須為會改變資料的請求實作 CSRF 防護。
若架構允許，可使用 __Host- 前綴、Path=/，且不要設定 Domain，避免其他子網域覆寫 Cookie。登入成功、權限提升、密碼變更與重新驗證後，都應輪替工作階段識別碼，以降低 session fixation 風險。不要把 token 放在 URL、前端錯誤訊息、分析事件或一般應用日誌中；即使日誌平台只有內部人員可存取，也不應成為另一套憑證資料庫。
- 限制範圍：只讓需要的主機與路徑收到 Cookie，避免為了方便設定過大的 Domain。
- 全程加密：登入頁與登入後頁面都只接受 HTTPS，並確認反向代理正確傳遞協定資訊。
- 避免持久化：高權限後台通常不需要長期 Cookie；若提供「記住我」，應使用可撤銷的獨立憑證，而非延長主要工作階段。
- 分離用途：瀏覽器工作階段、API token 與服務帳號應採不同生命週期和撤銷機制。
逾時必須由伺服器執行
可靠的策略通常同時包含閒置逾時與絕對逾時。閒置逾時限制無操作的暴露時間；絕對逾時則避免工作階段因背景輪詢或持續使用而永久有效。前端倒數與逾時提醒可以改善使用體驗，但不能作為安全控制；伺服器必須根據可信的最後活動時間拒絕過期憑證。單純移除瀏覽器 Cookie，並不代表伺服器上的工作階段已失效。
逾時長度應依工作內容決定。倉儲看板或監控牆可能需要長時間顯示，但不代表它也應長期保有修改權限；可將唯讀展示與管理操作拆成不同權限或工作階段。對於表單、批次匯入與長時間報表，應保存草稿、在逾時前提示，並把長任務交給後端工作佇列。不要為了避免使用者遺失輸入，就讓所有管理者全天維持登入。
- 一般內部操作：採合理的閒置期限，使用者活動可延長，但仍受絕對期限限制。
- 高權限後台：使用較短的閒置時間，並在權限提升後輪替識別碼。
- SSO 系統：區分身分提供者登入狀態與應用程式工作階段；上游仍登入，不等於本地工作階段不需逾時。
- 撤銷事件：登出、停權、密碼重設、角色變更與疑似外洩時，應讓相關工作階段立即失效。
以重新驗證保護真正敏感的操作
重新驗證適合用在改變權限、查看或匯出大量資料、修改付款或整合設定、產生 API 金鑰，以及執行不可逆操作之前。系統可要求近期完成的密碼、MFA 或 WebAuthn 驗證，並記錄此次驗證的時間與強度。這種 step-up 驗證比對整個系統一律縮短逾時更精準，也能減少一般工作被頻繁登入打斷。
重新驗證完成後，應輪替工作階段識別碼，並只恢復原本已授權的操作意圖。不要把密碼、一次性驗證碼或完整敏感表單內容暫存在 URL 或可被前端腳本讀取的位置。IP 位址與裝置特徵可作為異常訊號，但不宜直接綁死工作階段；企業 NAT、行動網路與 VPN 切換都可能造成誤判。
最後，建立中央撤銷能力與可查詢的稽核軌跡：記錄登入、識別碼輪替、重新驗證、登出、角色變更與拒絕原因，但不記錄原始 Cookie。若偵測到不合理的同時使用、裝置快速切換或高風險操作，可要求重新驗證或撤銷工作階段。Cookie、逾時與重新驗證必須由應用程式、SSO、反向代理及整合服務共同落實；跨系統環境複雜時，整合團隊的價值就在於把這些規則變成一致且可測試的控制。