Cookie 屬性詳解：SameSite、Secure、HttpOnly 與 CHIPS

HTTP 本身不會自動將兩次請求視為同一個已登入的會話（session）。伺服器可在回應中加入 Set-Cookie 標頭；瀏覽器儲存後，會在符合條件的後續請求中，以 Cookie 標頭傳回相應的值。

HTTP/1.1 200 OK
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

GET /account HTTP/1.1
Cookie: session=abc123

這只是通訊形式的示意，並非完整的 HTTP 記錄。abc123 是示例值，實際 session ID 必須難以猜測。

瀏覽器會根據 Domain、Path、有效期、安全屬性及自身政策決定是否傳送 Cookie。沒有指定 Domain 時，Cookie 只適用於設定它的主機；Path 則限制傳送路徑，並不是存取控制的保安邊界。

用戶毋須逐次選擇 Cookie，瀏覽器會自動附上符合條件的值。這令登入會話得以延續，但也意味非用戶本意的請求可能帶有登入憑證，是跨網站請求偽造（CSRF）必須處理的風險。

Secure Cookie 通常只會隨 HTTPS 請求傳送。登入會話應使用這項屬性，避免 Cookie 被附加到一般 HTTP 請求。

Set-Cookie: session=abc123; Secure

Secure 不會阻止 JavaScript 讀取 Cookie，也不能修補伺服器的會話管理錯誤。它不是磁碟儲存或瀏覽器擴充功能的保護機制，亦不會阻止跨網站指令碼攻擊（XSS）觸發的請求。部分瀏覽器對 localhost 有特殊處理；本機 HTTP 測試成功，不代表同一設定可用於公開的 HTTP 網站。

HttpOnly 阻止 JavaScript 經 document.cookie 等非 HTTP Cookie 介面存取該 Cookie。即使有指令碼被注入網頁，也能降低 session ID 被直接讀走的風險。

Set-Cookie: session=abc123; Secure; HttpOnly

然而，瀏覽器仍可在 JavaScript 發出的請求中附上這個 Cookie。攻擊者讀不到 session ID，也可能借用受害者的登入身份執行操作。

這並不代表所有 fetch 都會傳送 Cookie。fetch 的預設 credentials 模式為 same-origin；向另一個來源發送請求時，通常要指定 credentials: "include" 才能包含 Cookie，但 SameSite 和第三方 Cookie 政策仍然生效。防範 XSS 還須按輸出情境正確轉義內容、避免不安全的 HTML 插入，並採用適當的內容安全政策（CSP）。

SameSite 限制 Cookie 在跨網站請求中傳送。CSRF 攻擊會誘使已登入用戶的瀏覽器向目標網站發出非預期請求；SameSite 可以阻止部分情況，但不能判斷一項操作是否獲得授權。

明確設定 Lax 時，跨網站 iframe、fetch 和一般 POST 表單提交都不會帶上這個 Cookie。省略 SameSite 則未必相同：部分瀏覽器有相容處理，會讓剛設定的 Cookie 隨頂層 POST 請求傳送，例如設定後兩分鐘內。測試時不要將省略與明確設定 Lax 視為同一情況。

None 不能解除第三方 Cookie 封鎖。若網站用 GET 更改資料，Lax 允許的導覽仍可能觸發操作；不可信任的同網站子網域，也可能發出符合 SameSite 條件的請求。

應按應用程式需要加入 CSRF token、Origin 或 Referer 驗證、Fetch Metadata 標頭檢查及重新驗證身份。這些伺服器端防護不能一概由 SameSite 取代。

來源（origin）由網址的 scheme（例如 https）、主機和連接埠組成。包含 scheme 的網站判定（schemeful site）則以 scheme 和可註冊網域為基礎。以下比較一般頂層文件的網址：

iframe 的祖先文件也會影響同網站情境的判定，因此不能只比較兩個主機名稱。連接埠不同代表不同來源，但 Cookie 本身不按連接埠隔離。

Cookie 會否傳送、CORS 會否容許讀取跨來源回應，以及 JavaScript 能否存取另一份文件的 DOM，是不同問題。帶憑證的 CORS 回應需要以 Access-Control-Allow-Origin 指定請求來源，而非萬用字元，並設定 Access-Control-Allow-Credentials: true。讀取回應被 CORS 拒絕，不代表請求沒有送出或沒有被伺服器處理。

支援 Cookie 名稱前綴的瀏覽器會檢查額外條件；不合要求的 Cookie 會被拒絕設定。

只供單一主機使用的登入會話，可考慮 __Host- 以便檢查範圍。Path=/ 涵蓋該主機的所有路徑，不是按路徑或連接埠隔離應用程式。這些前綴不會自動加入 HttpOnly，也不是 XSS 防護。

CHIPS 的全名是 Cookies Having Independent Partitioned State。Partitioned 屬性在 Cookie 儲存時加入頂層網站分區，同時保留 Cookie 原有的主機或網域範圍；分區鍵中的網站亦包含 scheme。

Set-Cookie: __Host-chat=value; Secure; Path=/; SameSite=None; Partitioned

Partitioned 必須配合 Secure。這個跨網站嵌入例子還使用 SameSite=None，因為分區儲存不會取消 SameSite 的限制。

假設 support.chat.example 嵌入 retail.example 時設定了 Cookie，該 Cookie 便屬於 retail.example 的頂層網站分區。同一服務嵌入 news.example 時，不會收到 retail.example 分區的 Cookie；返回 retail.example 則可繼續使用原來的獨立狀態。

嵌入式聊天、地圖或其他元件，可利用這個機制按網站維持狀態。它不是讓無關網站共用同一登入狀態的方案。不支援 Partitioned 的環境可能忽略該屬性；若其他政策容許，Cookie 可能被當作普通未分區 Cookie。應在目標瀏覽器驗證，不能認定寫入屬性便必然做到隔離。

localStorage 的值可由 JavaScript 讀取。如果攻擊者能在應用程式的來源中執行指令碼，便可能直接竊取其中的 access token。

HttpOnly Cookie 雖然阻止直接讀取，但符合條件的請求仍會帶上它，CSRF 和 XSS 借用登入身份發出的請求仍須防範。兩種儲存方式面對的攻擊面不同，不能只問哪一種「永遠比較安全」。

會話設計須一併考慮 token 有效期、輪替、登出、伺服器端撤銷、重新驗證身份和權限檢查。儲存位置只是其中一環。

供伺服器使用、限定於單一主機的登入會話，可以由以下形式開始評估：

Set-Cookie: __Host-session=...; Path=/; Secure; HttpOnly; SameSite=Lax

用了外部身份提供者（IdP）或付款服務，不代表一定要選 None。先看返回網站時是頂層 GET、POST 回傳，還是 iframe，再判斷 Strict、Lax 或 None 是否合適。

如果嵌入式小工具需要由自己的 JavaScript 讀取狀態，並按頂層網站分開儲存，可考慮：

Set-Cookie: __Host-widget=...; Path=/; Secure; SameSite=None; Partitioned

小工具例子刻意沒有 HttpOnly，因為該例需要指令碼存取。若是只供伺服器使用的會話值，便應加入 HttpOnly。省略號只是佔位值，實作時須換成合適的 session ID 或其他狀態值。

這些標頭只示範屬性組合，並非完整的身份驗證系統。仍要檢查瀏覽器支援、Cookie 封鎖、CORS、iframe 限制、Storage Access API 的整合，以及伺服器的授權規則。

Secure 限制傳送連線；HttpOnly 限制指令碼存取；SameSite 限制跨網站傳送；Partitioned 在支援環境中按頂層網站分開狀態；__Host- 則約束 Cookie 的設定範圍。

HttpOnly 不能阻止 CSRF，Secure 不能阻止 XSS，SameSite 不能代替授權，Partitioned 也不能解決所有第三方 Cookie 問題。排查登入故障時，要分別檢查已儲存的 Cookie 和實際請求，再核對伺服器端的會話管理、CSRF 及 XSS 防護。