本文轉載自微信公眾號「微醫大前端技術」，作者廖宜康。轉載本文請聯系微醫大前端技術公眾號。

前言

作為前端開發，cookie是我們經常需要打交道的東西。我們用它來鑒權，用它來實現行為跟蹤，用它給無狀態的 http 協議以“狀態”。本文就聚焦這個小小的 cookie，把 cookie 掰開了，揉碎了講一講， 它是如何被我們利用的。

本文以 Chrome 瀏覽器 96.0.4664.55 版本作為客戶端環境，后續所有代碼說明都基于該版本的瀏覽器。主要闡述以下四點：

• cookie 的現有屬性
• cookie 如何被用來跟蹤我們
• cookie 前端管理實踐
• cookie 的未來

話不多說，開沖!

一、cookie 的屬性們

在詳細的屬性說明之前，我們先讓新老朋友重新熟悉一下 cookie。

cookie 官方定義：魔法曲奇餅，不是

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

由官方定義可知，cookie 是一個存儲在用戶端設備上的小塊數據。這里的定義指的是由 HTTP 請求的響應頭set-cookie創建的 cookie。現在我們也可以使用 document.cookie來訪問和手動創建第一方 cookie。

1.1 為什么要 cookie

大家都知道，因為有需求所以才有市場，技術也一樣，cookie 就是這樣出現的。cookie 的由來是著名的 Netscape 在給客戶開發電子商務程序時，客戶要求服務端不必須存儲事務狀態。那沒辦法，服務端不想存，只能客戶端出力了。由此 cookie 誕生了。我們常用的 http 協議是無狀態的協議，這也是為什么他這么快的原因之一。但很多時候我們需要知道是誰給我們發過來的請求，我們需要記錄用戶狀態。

所以 cookie 誕生的原因：

• 服務端不想存狀態
• 我們需要存狀態

可能有人會說，那我這個狀態存在sessionStorage里行不行，存在localStorage里行不行，甚至我自己放個自定義的參數放請求頭里來表示狀態行不行。

既然這么說了，當然是行的，瀏覽器發展到現在，很多存儲方式被用來替代 cookie，但是 cookie 仍然存在其獨特性。比如同域之間可共享，服務端可設置......所以具體怎樣的方案取決于你的實際場景。

1.2 屬性詳解

打開瀏覽器的devtool面板

可以看到，上面有 cookie 發展至今的所有屬性，那這些屬性分別代表什么呢?

cookie 屬性說明表

屬性名	屬性說明
name	cookie 的名字
domain	cookie 所屬域，domain表明哪些域名下可以使用該 cookie，重要的屬性。
path	cookie的使用路徑，path標識指定了主機下的哪些路徑可以接受 cookie。
Max-Age	cookie有效期，單位秒。如果為整數，則該cookie在Max-Age秒后失效。
Expires	cookie的失效時間，如果cookie沒有設置過期時間，那么 cookie 的生命周期只是在當前的會話中，關閉瀏覽器意味著這次會話的結束，此時 cookie 隨之失效。現在已經被 maxAge 屬性所取代，需要是一個日期對象。
HttpOnly	屬性可以阻止通過 javascript 訪問cookie。document.cookie讀取到的內容不包含設置了 HttpOnly 的cookie， 從而一定程度上遏制這類攻擊。
secure	它是一個布爾值，指定在網絡上如何傳輸cookie，默認為 false，通過一個普通的 http 連接傳輸，標記為 true 的cookie只會通過被 HTTPS 協議加密過的請求發送給服務端。
SameSite	限制第三方 url 是否可以攜帶cookie。有 3 個值：Strict/Lax(默認)/None。
SameParty	Chrome 新推出了一個 First-Party Sets策略，它可以允許由同一實體擁有的不同關域名都被視為第一方。之前都是以站點做區分，現在可以以一個 party 做區。SameParty就是為了配合該策略。（目前只有 Chrome 有該屬性）
Priority	優先級，chrome 的提案（firefox 不支持），定義了三種優先級，Low/Medium/High，當cookie大小超出瀏覽器限制時，低優先級的cookie會被優先清除。（目前只有 Chrome 有該屬性）

不廢話了，讓我們一個個開始講。(標綠色的屬性表示前端可以通過 js 直接操作的屬性)

name

name 主要注意同名的問題，cookie 設置時不同 domain，不同 path 可以使用相同的 name。如果 domain、path 相同，那么后設置的 cookie 會覆蓋先設置的。

除此之外還要注意一點，通過 js 操作cookie時，第一項永遠對應的是name=value。即document.cookie="path=/;name=test"這樣設置的結果不會是我們看上去的在/路徑下配置了一個 value 為test的cookie。而是設置了一個cookie的 name 是path value 是/。

value

cookie 的值，僅支持字符串，如果使用其他類型，會調用 toString()方法進行轉換。

domain

domain 要注意的點有很多，我們可以用它來實現前端跨域訪問，單點登錄(二級域名同域)，跟蹤用戶.....主要要注意的有以下幾個

• js 設置 cookie 配置 domain時，只能設置第一方的。如在 example.com 使用js設置cookie，如document.cookie = token=123;domain=test.com是不會生效的。
• js 設置cookie配置 domain時，如上一個例子，只要是手動配置該屬性，無論這個屬性前面有沒有寫明**“."**符號，都會自動加上 domian=.test.com，被配置通配域名的形式。
• js 獲取cookie時，目前通用的訪問方式仍然是document.cookie這一個 API，所以在獲取的時候我們是不知道當前的cookie是具體是屬于哪一個domain的。

path

• 設置cookie的該屬性時，該屬性的必須存在于當前url的pathname中，和domain類似，否則無法設置。
• 設置 path 時如果設置配置的是相對路徑，則會自動匹配設置為完整的pathname,如當前url為https://test.com/ab/cd，設置document.cookie = token=123;;path=ab，那么最終path就會是/ab/cd。
• 大家都知道cookie會在發送http請求時自動放入請求頭。如果cookie設置了該屬性，則會去匹配請求的路徑中是否包含該屬性的值，包含則會發送這個cookie。這里要注意一下path采用的是匹配的模式。如path為/test，那么/testtest也會匹配到。
• path屬性還存在一個作用，提升cookie的排序，通常我們設置cookie時，先設置的在前，后設置的在后。但是當cookie有path這個屬性時，有path的會被提升到最前面(chrome 瀏覽器，其他瀏覽器未實驗。)

這里還要注意下，設置path時，值要包含在當前url。但是我們最常用的ajax請求一般不是當前路徑，所以會攜帶不上這個cookie。要注意區分，不是當前路徑下的所有請求都會攜帶，而是請求的地址包含這個path才會攜帶。

Max-Age

cookie的刪除都是利用過期時間來實現，將其過期時間Max-Age設置為<= 0的整數則可以刪除該cookie。

• Max-Age如果設置的是非整數，則過期時間默認為session，即到頁面關閉即失效。
• Max-Age的時間是秒，設置為 10，則表示 10 秒后過期，是符合我們的預期的。注意和下面講的expires的區別。

Expires

Expires也是表示的過期時間，只不過相對max-age其出現的時間更早(對 IE8 以下有更好的兼容性)。現在更推薦使用Max-Age。使用Expires來設置過期時間有時候會出現一些我們困惑的情況。

• Expires首先接受的是一個Date對象，其次特別要注意的是，cookie的過期時間是基于UTC時間。而國內的標準時間是 GMT時間，比UTC時間要快 8 小時。我們通過該屬性設置過期時間時，如expires=${new Date()}。這里看著是把過期時間設置為了當前，cookie會立即失效，但是我們實際是把cookie的過期UTC時間設置為了當前時間，距離cookie真正失效還有 8 小時。有時我們通過expires去清除cookie時卻沒有清掉可能就是這個原因。

當我們同時設置Expires和Max-Age時，Max-age具有更高的優先級。

HttpOnly

該屬性主要是用來做基礎的 xss 攻擊防御，js 在設置cookie時是無法配置該屬性的。只有服務端通過set-cookie響應頭返回的字段才能配置該字段。但是這也只是防君子罷了，不用太過依賴該屬性。

Secure

secure和HttpOnly一樣，都是為了cookie安全打出的組合拳。和HttpOnly不同的是，它允許通過 js 配置。

這里插入一點我在實踐中發現的問題。有時候我們需要內網部署一些應用，通過前置機 ng 轉發請求的形式來訪問云端的服務。而訪問前置機一般是直接訪問ip的形式，這時候肯定不是 https 協議了。但是云端服務的響應頭set-cookie中如果含有secure屬性。(1)雖然可以通過 ng 傳回來，但是是寫不到內網機器里面的。(2)出現這種問題我們的處理方案通常是在 ng 這一層處理掉響應頭的secure。這里要注意一下360 瀏覽器會檢測到這種行為(不清楚具體原理)，仍然無法寫入cookie 。當前版本的 Chrome 則可以成功寫入，不排除未了來 Chrome 更新阻止的可能。

SameSite

本屬性是 chrome 51 新增的一個重要屬性。三個值的意義如下

• Strict: 僅允許發送同站點請求的的cookie。
• Lax: 允許部分第三方請求攜帶cookie，即導航到目標網址的 get 請求。包括超鏈接 ，預加載和 get 表單三種形式發送cookie 。chrome 80+ 版本后，默認就是該值。
• None: 任意發送cookie，設置為 None，必需要同時設置Secure=true，也就是說網站必須采用 https。

這里要區分一下跨站(cross-site)和跨域(cross-origin)兩者不是一個概念。跨域是指 portal、host、port 之中的任意一個不同都被視為跨域。而跨站則比較寬松，只要二級域名相同就是同站(二級域名指 .com 這種頂級域名的下一級，如 test.com)。

默認配置該屬性為Lax之后，主要影響的應該是我們的 post 表單、iframe、ajax 和 image，大家要注意。

SameParty

SameParty是 Chrome 為了 cookie的安全第三記組合拳。主要用來配合First-Party策略。所有開啟了 First-Party Sets 域名下需要共享的 Cookie 都需要增加 SameParty 屬性。如Set-Cookie:name=test;Secure;SameSite=Lax;SameParty。SameParty自身是沒有值的，但是設置他必須設置了Secure且SameSite不能是 strict

First-Party 策略在后面“Chrome 是如何做的”中會詳細說明。

Priority

上面說了很多可能有點啰嗦，這個屬性就。。。沒什么好說的，看上面的表格。

二、cookie 如何被用來跟蹤我們

上面一大段介紹看完，大家應該對現在的cookie有了全面的了解。那cookie又是如何被我們利用的呢?

cookie最廣泛的用途大家肯定都知道，無非傳遞傳遞鑒權信息，做做單點登錄，這也是用的最多的用法。但是cookie自誕生以來就是各大廣告商窺探用戶隱私的利器。例如我今天在某貓搜了個 xx 杯，第二天貼吧，微博到處都是這個東西的推銷廣告。仿佛全世界都知道我看了這個東西(事實上他們確實知道)。那么他們是如何做到的呢?

2.1 第三方 cookie

了解普遍的做法之前，我們先區分一下第一方cookie和第三方cookie。我們一般認為cookie的 domain 存在于當前域名或當前域名的父級的cookie稱為第一方cookie，否則為第三方cookie。雖然很多情況下“第三方”的cookie也是我們主動注入的罷了。

如下圖以某寶舉例：

.taobao.com下的就是第一方cookie，而這個.mmstat.com 很明顯就是第三方cookie了。

2.2 廣告與隱私

上面說到第三方cookie，可以說它是各種網絡廣告的罪魁禍首，而且是最便捷成本最低的那種。我們繼續以上面的某寶舉例。大家都能發現這個.mmstat.com這個域名。那這個網站是干什么的呢。

我首先去百度了下這個域名，域名本身無法訪問，但是在百度的結果下面倒是發現一些好玩的詞條??。

實際上他并不是什么不健康的網站，他是阿里旗下的一個廣告營銷平臺。

這里不是打廣告...只是讓大家知道他是做廣告營銷的就行了。

那他是如何運作的呢，我們可以根據請求來看。

標記用戶

首先我們打開某寶，可以看到第一次訪問 mmstat.com 這個域名是下面這個請求：

加載了一張幾乎不可見的 gif 圖片，同時通過 set-cookie 將第三方cookie寫入。

之后又請求了這張 gif 圖片。

將第一次獲得的信息傳入，完成了用戶的標記，阿里媽媽成功的知道了你是誰。當你打開其他接入阿里媽媽的網站時，比如視頻播放站某酷，你會看到你們存在一個相同的標記 ID。阿里媽媽知道是你小子剛才打開了我家的某寶然后又跑來某酷看電視來了。

獲取用戶足跡

我們知道用戶投廣告，希望看到的是廣告的高轉化率，那如何提高轉化率呢?最好的方式自然是將商品推薦給需要他的人群。那如何知道用戶需不需要這個商品呢?自然是記錄用戶的某寶搜索記錄，瀏覽記錄。將這些數據標記下來，就可以獲得商品的目標人群。

我們依然以某寶舉例，當我點進一個商品時，發送了這樣 5 個請求

最后一個請求沒什么好說的，就是傳入了一個 tmall 的跳轉路徑，因為我點擊的商品在 tmall 而不是某寶。我們重點看一下前四個請求。

根據 cookie的基本作用我們知道，這四個請求都攜帶了我們第一次打開某寶時所寫入的cookie信息，也就是標記我們是誰的信息，同時在這四個請求里傳入了一些參數來標記我們的行為，我們拉出來一個個分析下。

我們從上面的圖中可以看到，第一個和第二個，第三個和第四個請求幾乎是一摸一樣的。首先看下第一個和第二個請求

第一個請求參數 1-1

第二個請求參數 1-2

可以看到兩個請求參數幾乎是相同的，唯一的不同在于第一個請求的 gokey 中多了一個 aws=1的參數，當然不是某寶的開發我們自然是不知道每個參數的作用的，但是我們可以通過參數中包含的信息來推測。這里可以看到_p_url這個參數中包含的信息時比較明顯的。

從這個參數的值來分析，發現這個參數包含的信息就是我們是如何找到這個商品的。參數中明確的寫出我們是通過 s.taobao.com來搜索 q=%E8%83%8C%E5%8C%85到達此頁面的，q 的值就是我搜索的商品名“背包”。同時鏈接上還攜帶了一些其他參數，比如sourceId等。通過這些參數和一開始植入的第三方cookie，這里阿里媽媽就知道是"你在某寶首頁通過搜索背包進入的該商品頁"。那么你就被標記為了“一個需要背包的用戶”。搜索作為一種主動行為，占的權重肯定是比較高的，那這個信息就是非常有用的。

第三個請求和第四個請求的情況類似于第一、第二個，只不過包含的信息更詳細。第三個和第四個請求的地址相同，參數也幾乎相同，唯一的不同也是aws這個值。

我們以第三個分析一下：

可以看到，大量信息被放入 gokey 中。

轉碼后可以看到一些被發送的信息，例如

• serach_radio_all
• GongYingLianDIsts
• list_model
• isp4p
• item_click_form

上述信息大家通過定義的名稱也大致能猜出其包含的數據信息。通過以上信息阿里媽媽就記錄了你的這些行為：

• 你打開了淘寶
• 你在淘寶首頁搜索了背包
• 你在第一頁點進了一款背包
• 你只是看了看沒有購買
• ......

有了這些信息之后，當我們打開接入了阿里媽媽廣告的網站，比如某酷。你會發現他也有mmstat.com的第三方cookie嗎，并且存在一個id信息和你在逛某寶的時候是相同的。這時候廣告平臺就知道了：你小子剛才想買個包，現在又跑到某酷看劇來了，等會就給你推送點包的廣告，嘿嘿嘿!

而這一切的基礎就是通過一個小小的第三方cookie來對我們進行標記，完成用戶畫像，再將這些信息整合把商品推送給我們嗎，那賺我們的錢就像“搶劫”一樣。本來你只是產生了買個包的想法但是沒決定到底買不買，結果人家通過廣告投放不間斷的告訴你買個包吧，買個包吧，你的錢就這樣花出去了。

總結

簡單總結一下廣告跟蹤你基本就是三步走

• 首次訪問網站時通過第三方cookie植入將你標記。
• 瀏覽網站時通過植入的cookie不斷的向營銷平臺發送你的瀏覽足跡(幾乎精確到了每一步操作，一個點擊，一個停滯都會被記錄)。
• 在訪問其他社交網站時會值入相同的第三方cookie將你標記，同時給你推送相關廣告。

具體到實現的操作會比這復雜的多，希望大家可以根據上方的分析有所了解。

到這里大家可能就覺得有一種被監控的感覺。上述只是對購物網站的基礎分析，像我們日常用的最多的百度，微博等都接入了類似的廣告營銷平臺，再加上廣告聯盟的存在，可以說我們每個人在網絡上的每一步足跡都是被記錄在案的。只是這些數據可能分散在不同的廠商，加上國家監管，各大廠商也不會肆無忌憚。不過被監控的感覺始終是不舒服的，這也是為什么 Google 收到了超 100 億美元的關于隱私問題的罰款。而這一切都源于一個小小的cookie。

注：以上是我根據請求對廣告行為與cookie相關的一些分析，對某寶的分析僅僅是舉例，大家知道廣告平臺是怎么操作的即可。

三、cookie 前端管理實踐

說完了cookie的基本屬性與對我們的日常影響，我來談談在實踐中我是如何管理cookie的，供大家參考。

3.1 前端 cookie 常見問題

在聊如何做的之前我們先說說我在cookie上遇到過的一些問題：

• 主域名內嵌子項目，cookie 在不同項目間的行為難以統一
• cookie 鑒權相關操作在不完全了解的情況下不敢輕易修改
• 不同項目使用公司統一的二級域名情況下，因為 cookie 的 name 相同可能造成的混亂
• 項目中cookie如果某個屬性要調整或者項目要擴展子系統，可能會有遺漏
• 公司域名更改，cookie相關信息也要一并更改，可能遺漏

上述的問題不外乎三點 (1)cookie管理混亂;(2)cookie后續維護困難;(3)不同項目之間的 cookie沖突。

3.2 cookie 管理

既然存在這些問題那就想辦法解決，我這邊的做法是在數據初始化時進行管理 cookie，前端攔截未定義cookie的操作。

我想要管理好項目中所有的cookie,甚至處理好多項目同二級域名的問題，那就在項目初始化的時候就定義好所有要用的cookie。之后所有對cookie的操作都是對這些已定義的cookie進行處理。

首先我們建立一個對象來聲明我們項目中要使用的所有的cookie

// cookie-schema.js 
{ 
  cookie1: { 
    name: 'cookie1', // cookie 名稱 
    domain: 'root', // root-根域名 sub-當前域名及子域名 current-當前域名（默認值） 
    path: '/', // 匹配路徑 
    expires: 30 * 24 * 3600 * 1000, // 過期時間 30d 
    secure: false // https 傳輸 
  }, 
  cookie2: { 
    name: 'cookie2', 
    domain: 'sub', 
    expires: 30 * 24 * 3600 * 1000, // 30d 
    path: '/cookie-test', 
    secure: false 
  } 
} 

如上，cookie-schema.js中就是我們項目中所有要使用的cookie。這個可以是前端直接自己聲明，如果要處理不同項目之間沖突的問題，也可以專門建立數據中臺。將所有項目可用的cookie放在后臺配置，在項目初始化時去加載項目的可用cookie。

感興趣的同學可以配合使用我的這個小工具，有詳細說明：

**Cookie-Util：**https://github.com/Mrlyk/cookie-util

四、cookie 的未來

目前由于cookie帶來對種種隱私問題，各大瀏覽器廠商也開始限制第三方cookie。其中 safari 已經完全禁止了第三方cookie，但是對市場影響最大的依然是 Chrome 還沒有這么做，所以大家的感受不是很強烈。

4.1 Google 是如何做的

Google 由于cookie帶來的侵犯隱私問題，已經面臨超 100 億美元的罰款。因此 Google 在 2020 年初宣布 Chrome 將在未來的兩三年中完全禁用第三方 cookie。當然阻力是很大的，廣告行業的抵制聲音最大，可以理解??

到現在已經快兩年過去了，可以看到 Google 對cookie也是動作不斷。從 Chrome 51 推出 SameSite，到 89 版本推出 First-Party Sets 策略，還有Trust Tokens(這個筆者還未使用過)一步步在增加對三方cookie的限制，同時對歷史問題提出解決方案。

First-Party Sets

在上面介紹廣告是如何跟蹤我們的說明中，我們可以清楚的看到mmstat.com和taobao.com不是一個同一個域名，但是他們卻來自同一家企業。這種三方cookie可以看作是我們主動接入的，我們是不希望他們被瀏覽器干掉的。所以 Google 推出了First-Party Sets策略，配合 Chrome 的Saome-Party屬性，我們可以允許一個第一方party內的域名之間的cookie互相訪問。

當然為了防止該策略被濫用，Google 也做出了如下限制：

First-Party Sets 中的域必須由同一組織擁有和運營。

所有域名應該作為一個組被用戶識別。

所有域名應該共享一個共同的隱私政策。

同時，該策略不允許在不相關的站點之間交換用戶信息，所以單點登錄還是需要使用其他方案。

要使用該方案可以通過提供定義當前域名與其他域名的關系的清單文件來聲明它們是一個party的成員(或所有者)，文件需要是位于.well-known/first-party-set路由下的 JSON 文件

以 Google 官方的例子，假設a.example, b.example, c.example希望形成一個由a.example擁有的 first-party。那就需要聲明如下 JSON 文件：

// https://a.example/.well-known/first-party-set 
{ 
  "owner": "a.example", 
  "members": ["b.example", "c.example"], 
  ... 
} 
 
// https://b.example/.well-known/first-party-set 
{ 
 "owner": "a.example" 
} 
 
// https://c.example/.well-known/first-party-set 
{ 
 "owner": "a.example" 
} 

注意：該方案還在試用階段，chrome 89 ~ 93 可以試用

對 Google 的隱私策略有興趣的同學可以看一下這篇開者文檔：https://developer.chrome.com/docs/privacy-sandbox/

4.2 cookie Store API

The Cookie Store API provides an asychronous API for managing cookies, while also exposing cookies to service workers.

官方也新增了對cookie操作的新 API，相對于原來使用document.cookie繁瑣操作，這個 API 更加的方便，但是只能在 HTTPS 協議的下使用，同時兼容性還很差。使用方法類似于我上方的Cookie-Util工具，感興趣的同學可以看一下下面的官方文檔。

官方文檔：https://developer.mozilla.org/en-US/docs/Web/API/Cookie_Store_API

4.3 第三方 cookie 何去何從

透過上面的一系列分析，可以看出官方在未來主要打擊的是第三方cookie。不久 Chrome 也要完全禁用這種第三方cookie。那么沒了這些第三方cookie對我們的業務有什么影響呢?

• 單點登錄，如果之前是依賴三方cookie做淡點登錄的同學要特別注意尋找新方案了
• 異常追蹤工具，通常使用第三方cookie來標記用戶。被禁止后可能會造成 UV 暴漲的問題
• 用戶行為分析工具，失去這個標記后可能會失效
• .......

當然我們回到cookie作用的本質，是對用戶進行標記。那我們可以不可以用其他方法來標記用戶解決一些問題呢?當然是可以的，比如已經有很多人在用的瀏覽器指紋。

從普通用戶的角度上說，我們當然希望自己的隱私被保護的更好。但是隱私這堵墻也會協助這些巨無霸公司把自己的壁壘筑的越來越高。比如 Google 推出 FloC 模型來分析用戶群體的行為，當第三方cookie被屏蔽，廣告商要想好好的打廣告還得找回這些公司去使用他們的方案。

從技術的角度，我們更應該關注的是這些行業規范定制者的規范變更，對任何規范的變動保持警惕，及時處理對自己項目產生的風險。

參考

HTTP cookies: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/cookies)

Wiki cookie: https://en.wikipedia.org/wiki/HTTP_cookie

當瀏覽器全面禁用三方 cookie: https://mp.weixin.qq.com/s?__biz=Mzk0MDMwMzQyOA==&mid=2247490361&idx=1&sn=ebc8dcc4d095cc7ba748827dff158f2b&source=41

詳解 cookie 新增的 SameParty 屬性: https://juejin.cn/post/7002011181221167118

前往微醫互聯網醫院在線診療平臺，快速問診，3分鐘為你找到三甲醫生。(https://wy.guahao.com/?channel=influence)

廖宜康，Happy every day 前端開發工程師！