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

HTTP 本身不會自動把前後兩次請求連結成同一個登入工作階段。伺服器可以透過 Set-Cookie 回應標頭設定 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 只是佔位值，實際的工作階段識別碼必須難以猜測。

是否傳送 Cookie，取決於 Domain、Path、有效期限、安全屬性及瀏覽器政策等條件。省略 Domain 時，Cookie 只適用於設定它的主機。Path 限定傳送路徑，但不是存取控制的安全邊界。

瀏覽器會自動附上符合條件的 Cookie，讓登入狀態得以延續；也因此，使用者沒有打算執行的請求仍可能帶上身分憑證。這是跨網站請求偽造（CSRF）需要處理的風險。

帶有 Secure 的 Cookie 通常只會隨 HTTPS 請求傳送。登入工作階段應使用這項限制，避免 Cookie 被附加到一般 HTTP 請求。

Set-Cookie: session=abc123; Secure

Secure 不會自動保護磁碟上的資料，也不能修補瀏覽器擴充功能、伺服器工作階段管理或跨網站指令碼（XSS）帶來的風險。它不會阻止 JavaScript 讀取 Cookie，也不會阻止惡意指令碼發出請求。部分瀏覽器會特別處理 localhost；本機 HTTP 測試成功，不代表公開網站也能用 HTTP 傳送同樣的 Cookie。

HttpOnly 讓 JavaScript 無法透過 document.cookie 等非 HTTP Cookie 介面存取該 Cookie，降低 XSS 直接竊取工作階段識別碼的風險。

Set-Cookie: session=abc123; Secure; HttpOnly

不過，瀏覽器仍可能把它附加到 JavaScript 發出的請求。攻擊者即使讀不到 Cookie，也可能利用受害者的登入狀態執行操作。

這不表示每次 fetch 都會帶上 Cookie。fetch 的預設 credentials 模式是 same-origin；要傳送到不同來源，通常需要 credentials: "include"，而且仍須符合 SameSite 與第三方 Cookie 政策。HttpOnly 不能取代 XSS 防護，仍應依輸出情境正確跳脫內容、避免不安全的 HTML 插入，並搭配適當的內容安全政策（CSP）。

SameSite 決定 Cookie 是否符合跨網站請求的傳送條件。CSRF 攻擊會誘使受害者的瀏覽器向已登入的網站發出非預期請求；SameSite 能減少部分風險，但不能判斷使用者是否有權執行該操作。

明確設定 Lax 時，跨網站 iframe、fetch 或一般 POST 表單提交不會帶上該 Cookie。省略 SameSite 並不完全等同於明確設定 Lax：部分瀏覽器為了相容性，會在頂層 POST 請求中傳送剛設定的 Cookie，例如設定後兩分鐘內。測試時必須分開確認。

None 不會解除第三方 Cookie 封鎖。若網站用 Lax 允許的 GET 請求修改資料，也不能靠 Lax 阻擋這類操作；不受信任的同網站子網域也可能發出符合 SameSite 條件的請求。

伺服器仍須依應用情境使用 CSRF 權杖、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 名稱施加額外條件，不符合條件時拒絕設定。

若登入工作階段只供單一主機使用，可考慮 __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，屬於 retail.example 的頂層網站分區。同一個聊天服務內嵌到 news.example 時，不會收到前者分區的 Cookie；回到 retail.example，則可以繼續使用原本分開儲存的狀態。

這適合需要依網站維持狀態的內嵌聊天、地圖或其他元件，並不是讓所有網站共用同一個登入狀態的方法。不支援 Partitioned 的環境可能忽略這個屬性；若其他政策允許，Cookie 可能被當成一般未分區 Cookie。不能只看標頭就認定一定隔離，仍須在目標瀏覽器上驗證。

localStorage 的內容可由 JavaScript 讀取。如果攻擊者能在應用程式的來源中執行指令碼，存放其中的存取權杖就可能被直接竊取。

HttpOnly Cookie 可以阻止直接讀取，但符合條件的請求仍會帶上它，所以還是需要防範 CSRF，以及 XSS 利用登入狀態發出的請求。兩種儲存方式的攻擊面不同，沒有哪一種能省略工作階段設計。

應一併考慮權杖有效期、輪替、伺服器端撤銷、登出、重新驗證身分及授權檢查。只看儲存位置，無法判斷整個登入機制是否安全。

僅供伺服器使用、限定於單一主機的登入工作階段，可以從以下形式開始評估：

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。省略號只是佔位值，實作時須換成適當的工作階段識別碼或其他狀態值。

這些範例只示範屬性組合，不是完整的驗證系統。還須確認瀏覽器支援、Cookie 封鎖、CORS、iframe 限制、是否整合 Storage Access API，以及伺服器端的授權規則。

Secure 限制傳輸管道；HttpOnly 限制指令碼存取 Cookie；SameSite 限制跨網站傳送；Partitioned 在支援的環境中依頂層網站分開儲存狀態；__Host- 則限制 Cookie 的設定範圍。

每項設定都有邊界。HttpOnly 不能阻止 CSRF，Secure 不能阻止 XSS，SameSite 不能取代授權，Partitioned 也不能解決所有第三方 Cookie 問題。除錯時，要同時檢查瀏覽器儲存的 Cookie 與實際送出的請求，再檢查伺服器端的 CSRF、XSS 及工作階段防護。