客戶平台的登入 Cookie 應如何設定

先畫出登入狀態會經過的路徑

登入狀態 Cookie 通常保存一個不透明識別碼，讓伺服器辨認已登入顧客。預約、查訂單或修改帳戶時，這個識別碼會隨多個請求傳送。設定屬性前，先列出真正需要使用它的主機，例如網站、獨立結帳網址、帳戶網址及身份供應商返回路徑，並標示哪些請求由外站發起。這樣才可判斷設定是否配合實際流程，而不是照搬框架預設。測試亦須包含付款或登入後返回網站的步驟。

Cookie 只是登入保護的一層；伺服器端的到期、撤銷、權限檢查及防偽造操作仍然必要。OWASP 指出，單純刪除瀏覽器 Cookie 不會使已被盜取的識別碼失效；SameSite 也只是額外防線，不能代替防跨站請求措施。本文聚焦瀏覽器會傳送甚麼，以及頁面程式能否讀取。登出與帳戶復原應另設測試，避免看到 Cookie 屬性正確就誤以為整個系統已安全。

先說明登入狀態出錯的業務後果。過嚴的設定若令顧客付款返回後突然登出，可能造成重複嘗試或預約中斷；過寬的設定則令識別碼送往不需要的主機。應選擇能支援已記錄流程的最窄設定，並測試例外情況。遇到返回流程失效，不應立即放寬所有 Cookie，應先查明該步驟是否真的需要這個登入識別碼。

讓識別碼留在受保護的通道

登入識別碼應設定 Secure，整段已登入流程亦應使用 HTTPS。MDN 與 OWASP 均說明 Secure 限制 Cookie 只經加密請求傳送，但不能取代全程 HTTPS。要檢查發出 Cookie 的回應，以及之後帶着 Cookie 的請求，包括舊 HTTP 連結跳轉的情況。只有登入頁採用 HTTPS 並不足夠；若已登入頁面或資源退回 HTTP，仍有風險。反向代理可能在應用程式前終止 TLS，因此必須在實際部署環境檢查。

如果網頁 JavaScript 無需讀取登入識別碼，就應設 HttpOnly。這可阻止程式透過 document.cookie 讀到該值，減少注入程式盜取識別碼的途徑；但惡意程式仍可能發出自動附帶 Cookie 的請求，因此輸入處理與授權檢查不可省略。若前端聲稱需要原始識別碼才能顯示內容，應檢討設計：伺服器可回傳已授權的帳戶資料，而毋須把秘密交給頁面。啟用 HttpOnly 後要測試正常功能。

實際檢查應從 Set-Cookie 回應標頭開始，而非只截取瀏覽器 Cookie 面板。確認指定 Cookie 帶有 Secure 與 HttpOnly，再用開發者工具檢查後續哪些請求會附帶它。不要把正式環境識別碼貼進工單或分享截圖；可遮去數值，保留名稱及屬性供審查。登入時新發出的 Cookie 和延長登入狀態時重發的 Cookie 都要查，因為後者可能漏掉原有設定。

按實際跨站路徑選擇 SameSite

SameSite 決定瀏覽器在跨站請求時會否附帶 Cookie。Strict 排除跨站請求；Lax 容許某些使用安全方法的頂層跨站導覽；None 容許跨站用途，但必須同時設 Secure。這是瀏覽器傳送規則，並非公司的推廣分類。MDN 記錄各種屬性；OWASP 建議登入 Cookie 明確設定 Strict 或 Lax，不要依賴瀏覽器預設。可先在流程容許時試 Strict，再測試外部連結、身份驗證返回及付款返回，判斷是否需要 Lax。

例如顧客在比較網站點擊連結返回既有帳戶頁。使用 Strict 時，首次跨站導覽可能不帶登入 Cookie，顧客看似登出，直到再次進行同站導覽；Lax 可在符合條件的頂層安全導覽附帶 Cookie。這種差異影響連貫性，卻不足以把所有登入 Cookie 改成 None。若嵌入式跨站情境確實需要 Cookie，應記錄具體用途、瀏覽器行為及其他保護，不要為了無關小工具削弱主要帳戶 Cookie。

付款或單一登入返回流程最容易誤判 SameSite。返回請求的方法及瀏覽器情境，可能不符合所選屬性的條件。不要猜測；應在測試瀏覽器追蹤完整跳轉鏈，記下請求方法、是頂層頁面還是嵌入內容，以及 Cookie 是否送出。返回後還要完成帳戶或預約操作，因為某一步有 Cookie 不代表關鍵一步也有。若外部供應商改變返回方式，亦需保留可用的復原途徑。

限制可接收 Cookie 的主機

沒有設定 Domain 的 Cookie 只限發出它的主機使用；若把 Domain 設為母網域，符合條件的子網域也可能收到識別碼。MDN 與 OWASP 均有說明。若小企同時有宣傳網站、客戶平台及舊活動子網域，預設讓三者共用登入 Cookie 通常沒有充分理由。應列出真正需要登入狀態的主機，盡可能把主要帳戶識別碼限制在帳戶主機，其他服務則採用受支援的伺服器交接方式。

以 __Host- 作名稱前綴時，瀏覽器要求 Cookie 同時具備 Secure、Path=/，而且不得設定 Domain。這有助防止兄弟子網域設定同名、範圍更廣的 Cookie。若登入狀態只屬一個主機，而且應用可使用根路徑，便可考慮採用；若同一 Cookie 確實要跨子網域共用，就不適用。名稱前綴不能代替伺服器驗證，但可把預期的範圍規則交給瀏覽器執行，而非只留在註解中。

Path 可按網址路徑限制 Cookie 的傳送範圍，但不能作為同一主機上不同應用之間的強安全邊界；另一應用仍可能設定或影響同主機的 Cookie。Path 適合減少不必要傳送，不應單獨用來隔離管理區與客戶區。採用 __Host- 時須接受 Path=/ 的要求，並以主機分隔及伺服器授權建立真正隔離。也要檢查同名或近似名稱的舊 Cookie，避免程式解析重複名稱時出錯。

按顧客流程驗收設定

建立精簡測試矩陣，涵蓋首次登入、重新載入、外部連結返回、付款或身份驗證返回、更新帳戶、登入到期及登出。每一步記錄主機、請求情境、Cookie 屬性、是否附帶 Cookie，以及預期帳戶狀態。再以第二個瀏覽器設定檔測試，確認結果只屬正確的登入狀態。負責人應能同時證明識別碼受到保護、正常顧客流程不中斷。如第三方整合必須例外處理，應定期檢討其用途及期限。

假設預約平台位於 account.example，宣傳頁位於 www.example。團隊先把帳戶識別碼設為只限主機的 __Host- Cookie，並加上 Secure、HttpOnly，再測試 Strict。示例中，顧客從宣傳頁首次跳轉時看似登出，但其他預約操作正常。團隊可測試 Lax 是否保留預期返回流程，同時維持主機限制；不會因宣傳頁存在，就把 Domain 放寬至整個網域。這是示範決策，並非任何真實網站的測量結果。

只有安全與可用性兩方面都有證據，才應接受設定。應檢查接近正式環境的回應標頭及瀏覽器請求，同時完成依賴 Cookie 的顧客流程。若偏離較嚴格設定，須寫明具體原因及補充檢查。新增子網域、付款路線、身份服務或框架版本時，重新執行矩陣。最終目標是可維護的邊界：職員能說明識別碼送到哪裏、為何需要，以及缺失時系統如何安全處理。

到期時間要與關閉瀏覽器分開測試。設有 Max-Age 或 Expires 的 Cookie 可以留在裝置上；沒有這些屬性的通常稱為工作階段 Cookie，但瀏覽器恢復功能仍可能在關閉視窗後保留它。因此伺服器必須自行執行有效期限，拒絕已過期的識別碼。應測試閒置帳戶、填寫需時較長的預約表格，以及重新開啟瀏覽器的情況，並比較顧客所見與公司訂下的逾時政策。若提供「記住我」便利選項，應讓顧客明確選擇，不應在不知情下把所有已登入狀態延長。逾時後的畫面還應說明哪些未提交資料會保留，以及如何安全地重新登入完成原本操作。

更改設定時，舊 Cookie 可能與新 Cookie 同時留在瀏覽器。切換至只限主機的名稱前綴前，應先列出舊名稱、Domain 及 Path，否則伺服器可能讀到錯誤識別碼，令顧客在一頁顯示已登入、另一頁卻顯示登出。測試時既要用全新瀏覽器設定檔，也要用仍保存舊版本 Cookie 的設定檔。應按原本相同範圍清除舊 Cookie，並確認政策要求停用時，伺服器確實拒絕舊登入狀態。只測全新安裝無法發現這類轉換問題。