第三方 Cookie

本文介紹了什麼是第三方 Cookie,描述了與之相關的問題,並說明了如何解決這些問題。

什麼是第三方 Cookie?

一個 Cookie 與特定的域和方案(通常為 https)相關聯,如果設定了 Set-CookieDomain 屬性,則也可能與子域相關聯。

  • 如果 Cookie 的域和方案與使用者正在檢視的當前頁面(瀏覽器位址列中顯示的 URL)匹配,則該 Cookie 被認為來自與頁面相同的站點,並稱為第一方 Cookie
  • 如果域和方案不同,則該 Cookie 不被認為來自相同的站點,並稱為第三方 Cookie

注意:第三方 Cookie 有時也稱為跨站點 Cookie。這可能是一個更準確的名稱,因為第三方 Cookie暗示了第三方公司或組織的所有權。但是,無論您是否擁有所有相關的站點,其行為和潛在問題都是相同的。例如,一個站點可能會訪問來自其擁有的不同域的資源,例如影像。

當用戶首次訪問頁面、遵循同一站點上的另一個頁面的內部連結或請求駐留在同一站點上的資源(例如嵌入的影像、Web 字型或 JavaScript 檔案)時,可能會設定第一方 Cookie。

在以下常見情況下會發送第三方 Cookie

  • 當點選一個站點上的連結以導航到另一個站點時。
  • 當頁面嵌入來自其他站點的元件時,例如嵌入在 <iframe> 中的影像或其他文件(通常稱為第三方內容)。除了對元件的原始請求外,這些元件還可能會生成進一步的請求,從而設定更多第三方 Cookie。

第三方 Cookie 用於什麼?

點選連結到其他站點的連結時設定的第三方 Cookie 用於各種目的。例如,您可能有一個指向合作伙伴站點的關聯連結,並在使用者點選該連結時設定 Cookie,以便在購買特定產品時可以顯示帶有折扣的獎勵橫幅,或者可以將佣金支付給推薦人。

設定 Cookie 的第三方內容也有許多不同的用途。例如,您可能在多個不同但相關的站點上嵌入了登入小部件,該小部件在所有站點之間共享 Cookie 以確認使用者已登入,因此他們無需在每個站點上再次登入。

第三方 Cookie 的其他用例包括

  • 在多個站點之間共享使用者偏好或主題資訊。
  • 跨多個站點收集分析資料。
  • 計算廣告展示次數,並記錄使用者興趣,以使廣告技術平臺能夠投放更相關的廣告。

讓我們用一家虛構的公司進一步說明上面提到的登入小部件示例,該公司為其線上商店 (shop.site)、社群討論論壇 (forum.site) 和客戶服務與退貨 (service.site) 設定了單獨的域。

這三個站點中的每一個都嵌入了登入小部件,託管在 auth.site 上,以在站點之間持久儲存登入狀態。使用者可以登入到任何這些站點,在瀏覽器中為 auth.site 建立一個包含會話 ID 的 Cookie。當用戶轉到其他站點之一時,嵌入的 auth.site 例項將可以訪問使用者在第一個站點上登入時設定的會話 ID Cookie。它可以將其傳送到伺服器,檢查它是否仍然有效,並立即登入到該站點。

visual representation of the above third-party sign-in system description

第三方 Cookie 的問題是什麼?

上述用例聽起來足夠無害。但是,第三方 Cookie 也可以用於未經使用者同意的不正當目的,這些目的在技術上與有效用例無法區分。

點選指向第三方的連結或與嵌入在 <iframe> 中的第三方內容互動(例如,填寫表單或點選按鈕)可能會導致設定 Cookie,從而將使用者資訊交到他們意想不到的人手中。這些資訊可用於

  • 在使用者搜尋特定產品資訊時,使用目標廣告在網路上追蹤他們。
  • 向用戶傳送垃圾郵件或電話。
  • 操縱他們的行為,讓他們選擇某些選項以增加關聯收入或操縱統計資料。

單獨來看,這些情況已經夠糟糕了,但情況會變得更糟。第三方伺服器可以將跨不同站點設定的多個第三方 Cookie 中的資訊組合起來,以建立使用者瀏覽歷史記錄、興趣、習慣和個人資訊的詳細資料。這可用於建立令人毛骨悚然的、侵入性的使用者體驗,欺騙使用者,甚至實施身份盜竊。

在這種情況下,第三方 Cookie 被稱為跟蹤 Cookie

注意:透過不正當手段獲得的使用者資料也經常出售給其他第三方,從而進一步加劇了問題。

諸如歐盟的 通用資料保護條例 (GDPR) 和 加州消費者隱私法 (CCPA) 等法律透過要求公司對其設定的 Cookie 和收集的資訊保持透明來提供幫助。例如,要求客戶選擇加入此類資料收集,允許他們檢視公司掌握的關於他們的資料,以及如果他們希望刪除這些資料。

瀏覽器如何處理第三方 Cookie?

瀏覽器供應商知道使用者不喜歡上面描述的行為,因此都開始預設阻止第三方 Cookie,同時還在其原始碼中包含例外情況和啟發式方法,以解決流行網站上長期存在的第三方 Cookie 問題。

  • Mozilla 的 反跟蹤策略 已導致 Firefox 預設阻止來自已知跟蹤程式的第三方 Cookie(請參閱 Firefox 跟蹤保護增強型跟蹤保護)。Firefox 還為每個站點提供一個單獨的 Cookie 儲存,因此它們無法用於跨站點跟蹤使用者(請參閱 全面 Cookie 保護)。
  • Apple 也有一項類似的 跟蹤預防策略;遵循此策略導致了一系列類似的第三方 Cookie 保護措施,這些措施預設啟用;有關詳細資訊,請參閱 智慧跟蹤預防 (ITP)。
  • 在撰寫本文時,Google Chrome 僅預設在隱身模式下阻止第三方 Cookie,儘管使用者如果願意,可以透過 chrome://settings 將其設定為始終阻止第三方 Cookie。Google 已開始為一小部分 Chrome 使用者停用第三方 Cookie 以測試其影響,同時開發技術以在不需要第三方 Cookie 的情況下啟用關鍵用例。有關詳細資訊,請參閱 替換第三方 Cookie
  • Edge 阻止來自未訪問站點的跟蹤程式,並預設阻止已知的惡意跟蹤程式。在撰寫本文時,Microsoft 也開始探索預設在 Edge 中阻止第三方 Cookie。有關更多資訊,請參閱 跟蹤預防
  • Brave 瀏覽器 預設阻止跟蹤 Cookie。

可以透過 Firefox 的瀏覽器設定在逐個案例的基礎上允許使用第三方 Cookie。但在 Safari 中,控制權限更有限——您可以關閉跨站點跟蹤預防,但允許每個框架訪問第三方 Cookie 只能在程式碼級別透過 儲存訪問 API 完成。

注意:第三方 Cookie(或僅跟蹤 Cookie)也可能被瀏覽器擴充套件阻止。

Cookie 阻止可能會導致某些第三方元件(例如社交媒體小部件)無法按預期工作。隨著瀏覽器對第三方 Cookie 實施更多限制,開發人員應開始尋找減少對它們的依賴的方法:請參閱 替換第三方 Cookie

使用第三方 Cookie

使用 SameSite 啟用第三方 Cookie

使用 SameSite 屬性,伺服器可以指定是否/何時傳送第三方 Cookie。如果您未在 Set-Cookie 標頭中指定 SameSite,則使用預設值 Lax。這指示瀏覽器不要傳送第三方 Cookie,除非使用者從其他站點導航到 Cookie 的源站點。當您希望在使用者從其他站點導航到您的站點後立即傳送 Cookie 時,這很有用,例如,在他們到達後立即個性化體驗。

但是,如果您想在多個站點中嵌入 <iframe> 內的跨站點內容並依賴於第三方 Cookie 來實現功能,例如在上面我們看到的登入示例中,這將不起作用。在這種情況下,您需要顯式設定 SameSite=None 以允許瀏覽器傳遞這些 Cookie

http

Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly

請注意,如果設定了SameSite=None,則也必須設定Secure屬性——SameSite=None需要安全上下文。在上面的示例中,我們還設定了HttpOnly屬性,以停用 JavaScript 訪問 cookie(例如,透過Document.cookie)。儲存敏感資訊的 Cookie 應始終設定HttpOnly屬性——將其提供給 JavaScript 會非常不安全。此預防措施有助於緩解跨站指令碼 (XSS) 攻擊。

注意:用於敏感資訊的 Cookie 還應具有較短的生命週期

從第三方 Cookie 過渡

有多種策略可以幫助網站最大程度地減少在阻止第三方 Cookie 的瀏覽器中出現故障。

  1. 稽核您的第三方 Cookie 使用情況。Cookie 必須設定SameSite=None屬性才能在跨站點上下文中使用。因此,您可以透過在程式碼中搜索SameSite=None或檢查瀏覽器 DevTools 中儲存的SameSite=None Cookie 來識別第三方 Cookie,例如在Firefox 儲存檢查器中。Chrome 的問題面板報告了與第三方 Cookie 阻止相關的問題以及受影響 Cookie 的列表。
  2. 在阻止第三方 Cookie 的情況下測試您的功能,以檢視哪些功能出現故障。您可能會發現某些 Cookie 不再需要。
  3. 至少在最初,您可以使您的程式碼更具彈性,以便在第三方 Cookie 資料不可用時提供不太個性化的體驗,而不是完全中斷它。遵循優雅降級原則。
  4. 透過其他方式(如使用者調查或測驗)收集資料,或檢視您已有的資料以推斷趨勢(例如,產品訂單歷史記錄)。
  5. 使用替代的客戶端儲存機制,例如Web 儲存來持久化資料,或考慮使用伺服器端解決方案。
  6. 如果您的第三方 Cookie 僅在少量相關的已知網站之間使用,則可以使用儲存訪問 API和/或相關網站集僅允許這些特定網站訪問跨站點 Cookie。儲存訪問會提示使用者授予站點在每個框架中使用第三方 Cookie 的許可權。
    • 如果您已經使用儲存訪問 API 為 Firefox 或 Safari 實現瞭解決方案,那麼現在是時候根據 Chrome 的行為檢查您的實現,Chrome 的版本 119 已更新為提供完全支援。
    • 相關網站集可以被視為儲存訪問 API 的漸進式增強:API 可以以相同的方式使用,但集合中的網站不會提示使用者授予訪問第三方 Cookie 的許可權。
  7. 如果您的第三方 Cookie 正在與生成它們的頂級網站一對一地使用,您可以使用具有獨立分割槽狀態的 Cookie(CHIPS,也稱為分割槽 Cookie),選擇將您的 Cookie 儲存到每個頂級網站的單獨 Cookie 儲存區中。這隻需要向您現有的跨站點 Cookie 新增partitioned屬性。然後可以不受限制地使用它們,但不能與其他網站共享。請注意,CHIPS 目前僅限於 Chromium。

替換第三方 Cookie

對於希望停止使用第三方 Cookie 以尊重使用者隱私並最大程度地減少跟蹤同時繼續實施相關用例的開發人員,可以使用多種功能。其中一些功能處於早期實驗階段,但隨著您開始為未來做準備,值得考慮。

您可以開始探索 Google 的隱私沙盒專案中提供的不同功能,以檢視它們是否適合您的用例(這些功能目前處於實驗階段,並且僅限於 Chromium)。

  • 聯合憑據管理 (FedCM) API:啟用聯合身份服務,允許使用者登入多個站點和服務。
  • 私有狀態令牌:透過在站點之間交換有限的、非識別資訊來啟用反欺詐和反垃圾郵件。
  • 主題 API:啟用基於興趣的廣告和內容個性化。
  • 受保護受眾 API:使用來自一個應用或站點的資料,在使用者訪問另一個應用或站點時幫助選擇廣告。
  • 歸因報告 API:啟用廣告展示次數和轉化的衡量。

另請參閱