Chrome 80 後針對第三方 Cookie 的規則調整 (default SameSite=Lax)

Ian Hung
14 min readFeb 16, 2020

[April. 3 更新] 基於 COVID-19 的影響,Chrome 將暫時退回 SameSite Cookie 的發布,減緩對政府、衛生相關組織、銀行及其餘線上產業的影響。

TL;DR: Chrome 80 (released in Feb, 2020) 將針對 cookie 的發送機制有一些新的調整,將影響現有網站上仰賴第三方 cookie 實作的功能與使用者體驗本篇文章將解釋規則調整的技術細節(SameSite),造成的影響以及建議的修正方向。

Google 在 2019 年的 I/O 上宣布了其中一項公司的重要方向:隱私與安全。而各項產品也實則往對使用者更有保障的設計前進。其中 Cookie 這項技術可以說是在 Web 端實現追蹤、廣告投遞、個人化介面呈現等數位體驗的最基本工具。近日 Chrome team 發布了較大的聲明,陳述在接下來兩年除了會漸進式地移除對第三方 Cookie 的支援外,也同時將持續發展 Privacy Sandbox 等提升隱私的開放標準以及研發能夠偵測並掃除未經使用者意識或同意的數位指紋 (fingerprint) 系統。

而上述的聲明為一較大方向的發展描述,也會在眾多的使用者、媒體與流量方以及廣告方等多角度的討論下,持續朝對所有人都有助益的角度去發展。實則較為重要的乃是近期的發布: Chrome 上針對 3rd party cookie 的調整,會對多數的網站實作以及追蹤造成影響。以下也將針對該項更新解釋

  • 何謂 Cookie 以及 SameSite
  • Chrome 80+ 後的調整 & 檢測方式
  • 自家網站的程式碼該如何調整

※若本身已對 Cookie 以及 Samesite 的定義與設定熟悉的讀者,可以直接從「Chrome 80+ 針對 cookie 的讀寫的調整」讀起※

何謂 Cookie 以及 SameSite

由於 Cookie 在技術實作上行之有年,任意搜尋都可以找到滿滿的文章,這邊以官媒(?) Mozilla developers zone 的定義來解釋:

An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with the next request to the same server. Typically, it’s used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.

中文上可以理解成一塊能暫時存放在使用者瀏覽器的資料,並可以被提取用來記錄使用者的狀態、差異化使用者的體驗以及後續追蹤行為。而寫入的方式可以透過伺服器 (Server) 在回覆 (Response) 瀏覽器的請求 (Request) 時,在描述部份 (Header) 帶上 Set-Cookie: key=value 的欄位。Cookie 另外還有第一方 (1st party) 以及第三方 (3rd party)的分別,如果發送請求網址與當前網頁的網域一致,我們稱帶在請求上的 cookie 為 1st party cookie; 如果是網頁上一些置放在第三方網域底下的資源所發出的請求 (i.e. 圖片、追蹤程式碼..etc)所附掛的 cookie,則稱之為 3rd party cookie.

存取介面上來自不同 (第三方網域) 的資源,即可寫入 3rd party cookie

而 SameSite 即為一項在寫入 cookie (Set-Cookie: key=value) 時可加註的屬性 (attribute),會使瀏覽器依據 same-site / cross-site request 而對已寫入的 cookie 產生不同的行為。這邊的 site,指的是有相同的 <domain name>.<public suffix>,例如:yahoo.com 就是一個 site。只要 site 的部分相同,子網域也會當作是同一個 site,例如:new.yahoo.com 和 finance.yahoo.com 是同一個 site。值得注意的是除了「.com」、「.edu」這些常見的 <public suffix> ,也有像是「.github.io」這樣的 <public suffix>,所以 cats.github.io 和 dogs.github.io 不是同一個 site,儘管他們的「.github.io」部分是相同的。可以參考 Mozilla Foundation 維護的 Public Suffix List 看完整的清單。

以下針對 SameSite 三個值 None, Strict & Lax 產生的行為做進一步的說明:

SameSite=None

無論是 same-site 還是 cross-site 的 request 上, 都可以帶有該 cookie。

Scenario A

小明在 picture.com 上看了一張圖片 (https://picture.com/img/cat.jpg),該圖片的 response 帶有 Set-Cookie: cat_image_loaded=1, SameSite=None 的 header 敘述,cat_image_loaded=1 這個 cookie 便成功被寫入小明當前的瀏覽器。

兩天後小明在瀏覽 blog.com 這個網站時再度看到該圖片,則當 blog.comhttps://picture.com/img/cat.jpg 發出 request 請求該圖片的同時,cat_image_loaded=1 這個 cookie 也一併被發出。

SameSite=Strict

僅限 same-site request 才能夠帶有此 cookie。

Scenario B-1

小明在 picture.com 上看了一張圖片 (https://picture.com/img/cat.jpg),該圖片的 response 帶有 Set-Cookie: cat_image_loaded=1, SameSite=Strict 的 header 敘述,cat_image_loaded=1 這個 cookie 便成功被寫入小明當前的瀏覽器。

兩天後小明在瀏覽 blog.com 這個網站時再度看到該圖片,則當 blog.comhttps://picture.com/img/cat.jpg 發出 request 請求該圖片的同時,基於這是一個 cross-site request 且當前cat_image_loaded=1 已被註記為 SameSite=Strict ,所以該 cookie 不會被送出。

Scenario B-2

SameSite=Strict 的 Cookie 在 top-level navigation + GET 的情境下不會送出

小明在瀏覽 blog.com 上面的圖片時,發現圖片下方有一個能夠連回原站的連結 (https://picture.com/cat.html),便興奮地點了下去連回原站。在此同時瀏覽器便在 blog.com 的網域下對 https://picture.com/cat.html 發起了一個 request,基於這仍屬於一個 cross-site request 且當前 cat_image_loaded=1 被註記為SameSite=Strict ,因此 cookie 仍不會被送出。

SameSite=Lax

全部的 same-site request 以及部分 cross-site request 能夠寫入 cookie。這裡的部分包含以下能送出 request 的網頁元件:<a>, <link rel="prerender">, <form method="GET">.

Scenario C-1

小明在 picture.com 上看了一張圖片 (https://picture.com/img/cat.jpg),該圖片的 response 帶有 Set-Cookie: cat_image_loaded=1, SameSite=Lax 的 header 敘述,cat_image_loaded=1 這個 cookie 便成功被寫入小明當前的瀏覽器。

兩天後小明在瀏覽 blog.com 這個網站時再度看到該圖片,則當 blog.comhttps://picture.com/img/cat.jpg 發出 request 請求該圖片的同時,基於這是一個 cross-site request 且當前cat_image_loaded=1 已被標示為 SameSite=Lax ,所以該 cookie 不會被送出。

Scenario C-2

SameSite=Lax 的 Cookie 在 top-level navigation + GET 的情境下會送出

小明在瀏覽 blog.com 上面的圖片時,發現圖片下方有一個能夠連回原站的連結 (https://picture.com/cat.html),便興奮地點了下去連回原站。在此同時瀏覽器便在 blog.com 的網域下對 https://picture.com/cat.html 發起了一個 request,這個行為屬於一個 cross-site request ,但當前 cat_image_loaded=1 已被註記為SameSite=Lax 因此 cookie 會被送出

Chrome 80+ 後的調整 & 檢測方式

改變預設 SameSite=Lax 的 flag,可透過 chrome://flags 找到

Chrome 80+ 後將對所有未預設 SameSite 屬性的 Set-Cookie 預設為SameSite=Lax,意味著除了上述是 top level navigate + GET 的請求行為外,過往其餘 cross-site request 送發 cookie 的行為將預設被關閉。而若需發送第三方 cookie,需加上 SameSite=None; Secure 才會生效 (Secure 的用途為需透過 Https 發起的 cross-site request 才能發送 cookie)。

這項針對 Cookies 的調整正式釋出日期為 2020 年的 2 月 17 日,逐漸釋出到所有的 Chrome 80+ 瀏覽器,實際在瀏覽器開啟的是 #same-site-by-default-cookies 以及 #cookies-without-same-site-must-be-secure 這兩個 flag,詳細的時程相關可以參照這裡。另外以下有幾點細項與檢測方式:

怎麼檢測?

  • 透過這個網站可以檢查當前自己的瀏覽器是否已經更新為最新版本的 SameSite 規則,全部為綠色則為已開啟新規則。
  • 在 Console 會看到下圖這樣的訊息,告知當前開啟的網頁有 Cookie 尚未標注 SameSite 屬性(也等於被自動掛上 Lax)

額外細項

  • [Cross-site 登入機制緩衝調整] 為了避免上線後大量使用第三方認證與登入機制的網站失效,目前初步上線的行為為 “Lax + POST” 模式。意味著如果是透過跨網域 (cross-site) 登入且使用 POST 發送請求的機制時,未被標示任何 SameSite 屬性的 Cookie 將允許被掛在請求上發送,但時限為兩分鐘。這項機制未來有機會被移除。
  • [其他瀏覽器時程] Mozilla 預計在 version 69 後釋出,Microsoft 則預計為 version 80

自家網站的程式碼該如何調整

以下條列幾項網站主與開發者可以執行以避免網站服務功能失效的建議,若瀏覽器尚未被調整成該版本而需測試,則開啟上一段提及的 Chrome flag 做驗證。

  • 未來所有 Set-Cookie 的行為都預設加上 SameSite 的屬性,尤其針對會成為第三方用途的 cookie,務必掛上 SameSite=None; Secure。而針對只有在自己 domain 下會使用到的 Cookie,請加上 SameSite=StrictSameSite=Lax
    常見會使用到 cross-site request 的場景包含但不僅止於:
    - 使用 <iframe> 的嵌入式內容如影片、圖片、地圖或社群內容
    - 第三方 UI 元件如支付、月曆、社群分享按鈕
    - 發 POST 並會回傳 session_id 做驗證的流程
    - 追蹤程式碼、個人化用途以及一些需要仰賴 cookie 的 <script> & <img>
    - fetch() & XMLHttpRequest (可參考 fetch with credentials include)
    - Android App 裡面有使用 Webview 的地方
  • 尚有些瀏覽器 (Safari, 一些版本的 Safari, Chrome & UC Browser, 舊一點版本的 Chrome 支援的Android Webview) 未支持 SameSite=None,需額外實作例外處理,為支援名單可以參考這裡
  • 針對登入或金流驗證流程 (有機會開啟 cross-domain 或 redirect ) 需特別注意,即便有暫時性的 “Lax + POST” 機制,也仍然建議手動驗證整個流程是否可以正常運作。並評估未來在該機制拿掉後,當前的登入或驗證機制是否仍然可行
  • 企業 IT 管理員若評估當前服務會影響內部大量系統的登入或驗證機制,請參考 SameSite Policies 作出對應的預先調整
  • 如果使用 AMP 的服務,建議導入 Sign-Exchange 以讓 AMP Cache 的 Domain 變為同源。(Ref: https://blog.amp.dev/2020/01/27/cookie-classification-on-amp/)

Reference

最後附上 Google 公告的英文相關消息與解釋,上述的內容已包含多數公告提及的重要項目,但也鼓勵大家參照原文以做出更完整的修改評估。

Kind thanks for contributions and feedback from Fish Chan, Irene Chang & Zoe Peng, and for slightly discussion between Clay Liao, Paul Li & Ray Tseng.

--

--

Ian Hung

Taiwanese, work at Google Singapore as a Web Ecosystem Consultant, whisky lover & city explorer.