SameSite Cookie 食譜

Rowan Merewood

Chrome、 Firefox、 Edge、 和其他組織正配合 IETF 來變更其預設行為 提案 Cookie 成效提升 如此一來：

• 不含 SameSite 屬性的 Cookie 會視為 SameSite=Lax， 這表示預設行為是將 Cookie 限制為第一方 只有背景資訊。
• 用於跨網站使用的 Cookie「必須」將 SameSite=None; Secure 指定為 允許將第三方內容納入第三方內容。

此時，請務必更新 來自第三方 Cookie，避免日後遭到封鎖。

跨網站或第三方 Cookie 的用途

有幾個常見用途和模式需要使用 Cookie 或錯誤資訊如果您提供或仰賴上述其中一種使用方式 請您或供應商將他們的 Cookie 更新為 可確保服務正常運作。

<iframe>中的內容

<iframe> 中顯示的其他網站內容位於第三方 相關資訊標準用途包括：

• 從其他網站分享的嵌入內容，例如影片、地圖、程式碼範例、 以及社群媒體貼文
• 來自外部服務的小工具，例如付款、日曆、預約及 預訂功能
• 社交按鈕或反詐欺服務等小工具，讓人較不易察覺 <iframes>。

Cookie 可用於其他目的，包括維持工作階段狀態、儲存 一般偏好設定、啟用統計資料或針對使用者的個人化內容 現有帳戶。

由於網頁本身是可組合的，因此 <iframes> 也會用來嵌入 在頂層或第一方情境下觀看的內容。這個網站中的所有 Cookie iframe 使用中的每一個 Cookie 都視為第三方 Cookie。如果您是 建立您希望其他網站嵌入的網站，並且需要 Cookie 才能嵌入網站 您也需要確保標記為可供跨網站使用，或 即使沒有這些限制 也能優雅復原

「不安全」跨網站要求

「不安全」這部分可能聽起來很有趣，但牽涉到 最終要變更狀態網路上主要發出的 POST 要求。餅乾 標示為 SameSite=Lax 時，會在安全的頂層導覽中傳送 (例如點選 連結前往其他網站。但是，將 <form> 提交至 使用 POST 的其他網站不含 Cookie。

這個模式適用於可將使用者重新導向至遠端元件的網站 服務在傳回之前執行某些作業，例如重新導向至 第三方識別資訊提供者使用者離開網站前，Cookie 指的是 含有單一使用權杖的集合，並預期這個權杖可 檢查傳回要求 跨網站偽造要求 (CSRF) 網路攻擊。如果傳回要求是透過 POST 傳遞，請將 Cookie 做為 SameSite=None; Secure。

遠端資源

網頁上的任何遠端資源 (例如來自 <img> 標記或 <script> 標記) 可能仰賴隨要求一併傳送的 Cookie。常見用途包括 追蹤像素和個人化內容

這也適用於使用 fetch 或 XMLHttpRequest。如果使用 fetch() 呼叫 credentials: 'include' 個選項， 這些要求可能已包含 Cookie XMLHttpRequest 的 Cookie 通常會由 withCredentials 值 敵對 true 的比賽。這些 Cookie 必須適當加上標記，才能加入 跨網站請求

WebView 中的內容

平台專屬應用程式中的 WebView 是由瀏覽器所驅動，開發人員必須 測試應用程式是否也適用這些限製或問題 開啟應用程式的 WebView

Android 也允許特定平台的應用程式直接使用 CookieManager API。 如同使用標頭或 JavaScript 設定的 Cookie，建議您加入 SameSite=None; Secure 適用於跨網站使用。

立即導入 SameSite 的方法

將只在第一方情境下需要的所有 Cookie 標示為 SameSite=Lax 或SameSite=Strict。如果不標示這些 Cookie 並且仰賴預設的瀏覽器行為來處理這些要求， 版本的瀏覽器不一致，且可能會觸發每個版本的控制台警告 Cookie。

Set-Cookie: first_party_var=value; SameSite=Lax

請務必將第三方內容所需的 Cookie 標示為 SameSite=None; Secure。這兩個屬性皆為必填。如果將 如果沒有 Secure，系統將拒絕 None，Cookie 將遭到拒絕。為了反映差異 實作瀏覽器時，您可能需要 請參閱「處理不相容的用戶端」一文中的策略。

Set-Cookie: third_party_var=value; SameSite=None; Secure

處理不相容的用戶端

因為這些變更包含 None 和更新預設行為仍維持不變 相對新、不同的瀏覽器處理問題的方式也不一樣。你可以參考 前往 chromium.org 的更新頁面 ，但這份清單可能不完整。

其中一個可行的解決方法是，同時以新樣式和舊樣式設定每個 Cookie：

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

實作較新行為的瀏覽器會使用 SameSite 設定 Cookie 值。沒有實作新行為的瀏覽器會忽略該值，然後 3pcookie-legacy Cookie。處理包含的 Cookie 時，你的網站應該 先檢查有無新款 Cookie，然後改回 從舊版 Cookie 消失

以下範例顯示如何在 Node.js 中執行此操作 (使用 Express 架構及其 cookie-parser 中介軟體：

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

這種方法需要您額外設定多餘的 Cookie， 發生變更時會產生變更。不過 涵蓋所有瀏覽器 (無論其行為為何)，並保留第三方 Cookie 以及功能正常運作

或者，您可以在發生用戶端錯誤時，使用使用者代理程式字串偵測用戶端 系統已傳送 Set-Cookie 標頭。詳情請參閱 不相容用戶端清單 並根據您的平台使用適當的使用者代理程式偵測程式庫 舉例來說，ua-parser-js 程式庫 在 Node.js 上使用這個方法只需要完成一項變更，但使用者代理程式 網路檢查功能不一定能攔截所有受影響的使用者。

支援語言、程式庫和架構的 SameSite=None

大部分的語言和程式庫都支援 SameSite 屬性： Cookie。不過，由於新增 SameSite=None 的速度還是 您最近可能需要處理一些標準行為。 這些行為均記錄在 GitHub 上的 SameSite 範例存放區。

取得說明

網路上的每個位置都會使用 Cookie，很少需要開發團隊 能夠全面掌握網站集的擺放位置和使用位置 適合跨網站使用的情況遇到問題時，您可能是第一次遇到 所有人都遇到這個問題，請隨時與我們聯絡：

• 前往 GitHub 上的 SameSite 範例存放區。
• 前往 "samesite"在 StackOverflow 上標記該標記。
• 如果是 Chromium 的行為問題，請在 Chromium Issue Tracker：
• 您可以透過以下網站追蹤 Chrome 的進度： 「SameSite」更新資訊頁面。