騰訊三面：Cookie的SameSite瞭解吧，那SameParty呢？

語言: CN / TW / HK

時間 2022-04-16 22:29:56 SegmentFault博客

主題: Cookie

大家好，我是年年！

今天介紹的是三方cookie相關的內容，本文會講清：

什麼是三方cookie？
same-site的變化是什麼，對我們的業務有什麼影響？
為什麼有了same-site，還需要same-party？

文章首發在我的公眾號：前端私教年年

什麼是三方cookie

三方指的是非同站，這個同站和同源協議中的源 origin 不同，它的要求更寬鬆。

同源協議中的源是由「協議+域名+端口」三者一起定義的，有一個不同就不算同源，而同站只受域名的約束，並且還不要求一模一樣——只要「有效頂級域名+二級域名」相同，都算同站。

有效頂級域名是由Mozilla維護的一份表格，其中包括 .com 、 .co.uk 、 .github.io 等。所以ai.taobao.com和www.taobao.com是同站的，因為它們的頂級域名（.com）+二級域名（.taobao）相同。

現在知道了什麼是站，就可以很簡單區分了：

打開開發者工具的application，domain一列中顯示和當前域名不同的就是三方cookie

如何攜帶三方cookie

cookie的攜帶是瀏覽器自動的操作，規則是「不認來源，只看目的」，下面會講清這句話的意思。

cookie下發

首先，需要先了解cookie的下發，服務端會將其下發到瀏覽器，方法是通過響應頭中的 set-cookie 字段

裏面還包括一些配置屬性，關鍵的是其中的domain

domain

指定cookie未來使用時，可以被攜帶到哪些域名。其值可以設置為當前服務端的父級域名或其本身，比如 ai.taobao.com 設置的cookie的domain可以為 .taobao.com ，所設置值的所有子域名都可以使用，比如 www.taobao.com 。

如果不設置，會默認為當前域名 ai.taobao.com ，並且只有自己可以使用，子域名 sub.ai.taobao.com 都不能使用，適用範圍就小了很多，所以一般都會設置。

但是不能設置為跨站點的 .baidu.com ，也不能是頂級域名 .com 。

其餘的屬性還有這些：

path：指定cookie未來使用時，可以被攜帶到合法域名的哪些URI。和domain很像，也只能設置為當前路徑的父級路徑或其本身,設置值的所有子路徑都可以訪問。
expire/max-age: 指定cookie的有效期，其中expire是一個絕對時間，max-age是相對時間，單位是秒，兩者同時存在時，max-age優先級更高；如果兩者都沒有，則為會話級別的cookie，即用户關閉瀏覽器時失效。

Set-Cookie: id=nian; Expires=Wed, 30 Aug 2022 00:00:00 GMT; Max-Age=3600

secure：只能在HTTPS環境中被下發以及攜帶
http-only：禁止客户端腳本通過 document.cookie 獲取 cookie，避免 XSS 攻擊。
還有下面會重點講解的same-site和same-party

Cookie攜帶

上面提到，cookie的domain字段很關鍵，它規定請求哪些域名才會攜帶，注意，這裏指的是請求目的地的域名。

舉個例子，首先我通過響應頭在瀏覽器中設置了一個cookie，domain是 .a.com

set-cookie: id=nian; domain=.a.com;

現在有三個請求：

網頁 www.a.com/index.html 的前端頁面，去請求接口 www.b.com/api
網頁 www.b.com/index.html 的前端頁面，去請求接口 www.a.com/api
網頁 www.a.com/index.html 的前端頁面，去請求接口 www.a.com/api

有點繞，可以暫停思考10秒，哪個請求會帶上之前設置的cookie呢？

答案是2、3都會帶上cookie，因為cookie的取用規則是去看請求的目的地，2、3請求的都是 www.a.com/api 命中 domain=.a.com 規則。

這就是「不認來源，只看目的」的意思，不管請求來源是哪裏，只要請求的目的是a站，cookie都會攜帶上。

通過這個案例也可以再回顧一下：3的這種情況的叫第一方cookie，2的這種情況叫第三方cookie。

限制三方cookie的攜帶

「不認來源，只看目的」規矩在2020年開始被打破，這種變化體現在瀏覽器將 same-site:lax 設置為默認屬性。

chrome操作比較平緩，目前可以手動設置 same-site:none 恢復之前規則。

但在safari中如果這樣設置，會被當作 same-site:strict

可以看到，在safari中使用的全是第一方cookie，直觀的體驗就是在天貓登錄完，打開淘寶，還需要再登錄一次。

也就是説現在cookie的取用是「既看來源，又看目的」了。

SameSite

上面提到的same-site是cookie的一個屬性，它制約第三方cookie的攜帶，其值有三個 none 、 strict 、 lax 。

strict 代表完全禁止三方cookie，這是最嚴格防護，可以避免被CSRF攻擊，但缺點也很明顯，像天貓、淘寶這種同屬一個主體運營的網站不得不重複登錄；
none 代表完全不做限制，即之前「不認來源，只看目的」的cookie取用原則；
Lax 則是折中，在某些情況下會限制三方cookie的攜帶，某些情況又放行，這也是瀏覽器的默認值（包括safari）。

在safari，same-site的默認值是lax，如果把它設置為same-site:none，會適得其反，被當作strict處理

SameSite的修改

可以這麼理解，瀏覽器將same-site的默認值從 none 調整到了 lax

same-site:lax的具體規則如下：

類型	例子	是否發送
a鏈接	`<a href="..."></a>`	發送
預加載	`<link rel="prerender" href="..."/>`	發送
GET 表單	`<form method="GET" action="...">`	發送
POST 表單	`<form method="POST" action="...">`	不發送
iframe	`<iframe src="..."></iframe>`	不發送
AJAX	axios.post	不發送
圖片	`<img src="..."></a>`	不發送

而在這之前是會全部發送的。

SameSite修改帶來的影響

像a鏈接這種，沒有受到影響，依舊會帶上三方cookie，這樣可以保證從百度搜索中打開淘寶，是有登錄狀態的。

但是對大部分業務的影響是巨大的，比如監控埋點系統。

埋點監控SDK是用圖片的src去做請求的發送的，從上面的表格可知，變成lax後默認不發送了，這時用户的身份便無法確認，UV也沒法統計了。

為什麼埋點監控用會圖片的src，之前詳細寫過一篇文章，戳這裏

為了解決這些問題，大部分公司目前的解決方案是設置 same-site:none 並且配合 secure ，就可以像以往一樣，繼續攜帶第三方cookie。

但這不是版本答案。

SameParty

上面説到，為了繞開瀏覽器對三方cookie的限制，保障業務的正常，我們的解決方式是把same-site又設置回none。

但這不是長久之策，一來，瀏覽器把same-site的默認值從從 none 調整到 lax 可以避免CSRF攻擊，保障安全，可我們為了業務正常運行，卻又走了回頭路；二來，chrome承諾2022年，也就是今年，會全面禁用三方cookie，屆時和在safari一樣，我們沒法再用這種方法去hack。

如果我們不想使用same-site:none，或者説，未來用不了這種方式了，same-party將是我們的唯一選擇。

什麼是 SameParty

繼續沿用阿里系的例子，same-party可以把 .taobao.com 、 .tmall.com 和 .alimama.com 三個站合起來，它們設置的cookie在這個集合內部不會被當作第三方cookie對待。

首先需要定義First-Party集合：在 .taobao.com 、 .tmall.com 和 .alimama.com 三個站的服務器下都加一個配置文件，放在 /.well-know/ 目錄下，命名為 first-party-set 。

其中一個是“組長”，暫定為 .taobao.com ，在它的的服務器下寫入

// /.well-know/first-party-set
{
  "owner": ".taobao.com",
  "members": [".tmall.com", ".alimama.com"]
}

另外兩個是組員：

// /.well-know/first-party-set
{
  "owner": ".taobao.com",
}

並且，在下發cookie時，需要註明same-party屬性：

Set-Cookie: id=nian; SameParty; Secure; SameSite=Lax; domain=.taobao.com

這樣，我們打開 .tmall.com 的網站，向 .taobao.com 發起AJAX請求，都會帶上這個cookie，即使當前的same-site屬性是lax，因為這集合中的三個域名都會被當作一個站對待，也就是説，在瀏覽器眼中，這個cookie現在就是第一方cookie。

而不在集合中的 baidu.com 發起的AJAX請求則不會帶上。

需要注意的是，使用same-party屬性時，必須要同時使用https(secure屬性)，並且same-site不能是strict。

結語

對三方cookie的限制一是為了瀏覽器安全，但在國外推動的更重要原因是個人的隱私安全。但不論是出於什麼目的，這種改變都會對當前的業務架構造成很大的影響。

same-site:lax 變成默認是一個暫時的預警，它限制了特定場景下的第三方cookie使用。目前處於比較柔和的過渡期，因為在大部分瀏覽器中，我們可以簡單地將它調整回 same-site:none 來解除這些限制，和以前一樣暢通無阻。

但未來這項限制終將無法脱下， same-party 才是版本答案，有了它，我們可以靈活定義哪些站屬於業務意義上的“第一方”，哪些才是我們想要的“第三方”。

如果覺得這篇文章對你有幫助，請點個贊還有關注吧！

你的支持是我創作的動力:heart:

「其他文章」