如何用Chrome读懂网站监测Cookie
作者 | 朱順意
責編 | 李雪敬
出品?| CSDN云計算（ID：CSDNcloud）
網站監測工具用于標識用戶的 Cookie 分為第1方 Cookie 和第3方?Cookie，這兩者本質上沒有什么區別，只是身份不同。Cookie 有 Domain?屬性，當 Cookie?的 Domain?與當前訪問的域名不同時，這個 Cookie?為第3方?Cookie，反之為第1方?Cookie。
由于 Domain 的不同，第1方 Cookie 記錄的是用戶在指定站點的行為，第3方 Cookie 記錄的是用戶在不同站點的行為。網站監測工具為你的站點創建了第1方 Cookie，這個 Cookie 屬于你的站點，僅能用于記錄你站點的用戶行為，同時網站監測工具也創建了第3方 Cookie（屬于它自己的Cookie），這個 Cookie 用于記錄所有部署了監測代碼站點的用戶行為。
以 Chrome 為工具，我們來看看 Cookie 是怎么樣的。
查看Cookie
步驟：打開 Chrome > 訪問 www.zhihu.com > 按下 F12 打開 DevTools > 切換到 Application 面板 > 打開左側 Cookies > 選擇 www.zhihu.com。
可以看到，Cookie 有各種屬性：
? Name：Cookie 名稱。
? Value：Cookie 值。
? Domain：Cookie 域名，代表能讀寫這個 Cookie 的域。假設在 DevTools 這里 Domain 為“.zhihu.com”（最前面帶點），則所有以“zhihu.com”結尾的域名都能讀寫這個 Cookie。假設 Domain 為“zhihu.com”(最前面不帶點)，此時 Cookie 僅為當前域所用。如果創建 Cookie 時不聲明 Domain，則 Domain 的最前面不帶點。如果創建 Cookie 時聲明 Domain，則無論聲明時有沒有帶點，在 DevTools 都會自動帶點，所聲明的域及其所有子域都能讀寫這個 Cookie。
? Path：Cookie 的有效訪問路徑，代表基于 Domain 下能讀寫這個 Cookie 的頁面路徑。假設 Domain 為 “.zhihu.com”，Path 為 “/”，則 zhihu.com 根目錄下所有頁面路徑都能讀寫這個 Cookie，如果 Path 為 “/question”，則 Cookie 僅在 question 頁面路徑下能被讀寫。
? Expires/Max-Age：Cookie 的過期時間，采用協調世界時(UTC)，與中國標準時間相差8小時。時間格式為 ”yyyy-mm-ddThh:mm:ss.sssZ”，T是分隔日期和時分秒的符號，”.sss” 代表毫秒，Z 表示 UTC 零時區。如果創建 Cookie 時默認不填，則此值為 Session，即關閉瀏覽器自動清除 Cookie。
? Size：Cookie 的大小。
? Httponly：是否允許客戶端讀寫Cookie，常見客戶端方法有 document.cookie。
? Secure：是否只能通過 Https 協議讀寫 Cookie。
? SameSite：跟第3方 Cookie 的讀寫限制有關，我們后面會講到。
? Priority：Cookie 的優先級，有 Low/Medium/High 這3種值，當 Cookie 超出瀏覽器存儲上限時，優先級低的 Cookie 將被清除。
第1方Cookie
網站監測工具標識用戶常用第1方Cookie，即Cookie的Domain為當前訪問站點的頂級域名。以Google Analytics為例（以下簡稱GA），下面這個藍底色的就是GA標識用戶的Cookie，它的Domain為”.zhihu.com”，所以它為第1方Cookie。
GA 標識用戶的 Cookie，Domain 為 ”.zhihu.com”，意味著這個 Cookie 在 zhihu.com的所有子域名下，都能被讀寫。因此，zhihu.com、www.zhihu.com、daily.zhihu.com、static.daily.zhihu.com 在用同一套監測代碼的時候，標識用戶所用的 Cookie 是一樣的。
GA 標識用戶的 Cookie 名稱為 “_ga”，它的值是這樣構成的：
? 版本號：GA1 為版本相關信息，所有被 GA 監測的站點幾乎都一樣。
? Domain長度：2為 “_ga” 這個 Cookie 的 Domain 長度，”.zhihu.com” 長度為2。當被監測的站點為 ”xxx.com.cn” 時，Domain 長度為3。當被監測的站點使用多級域名例如 ”www1.www2.xxx.com” 時，在 GA 的這個 Cookie，Domain 依然為頂級域名 ”.xxx.com”，長度依然為2。
? 唯一的隨機數：GA 生成的隨機數字，具有唯一性。
? 首次訪問的時間戳：用戶首次訪問站點，GA 獲得的時間戳，你可以打開 Chrome DevTools 的 Console 面板，用 new Date 把它轉換成中國標準時間。這個時間再加上2年，等于這個 Cookie 的 Expires/Max-Age 的中國標準時間，也就是說 GA 標識用戶的 Cookie 有效期為2年，2年之后 Cookie 被清除。
從GA的JS代碼，也能看出這個值的構成：
那么，這個第1方 Cookie 屬于被監測的站點，但又是由 GA 創建，這是怎么一回事？
GA 的 JS 代碼包含創建 Cookie 的方法，這段 JS 被嵌入到網站，相當于網站自己創建了 Cookie，因此這個過程不存在跨域的問題。目前市面上的網站監測工具都是用這樣的方法來創建第1方 Cookie 的。換言之，GA 這段 JS 也能夠讀寫這個站點的所有第1方 Cookie(已設置 Httponly 的除外)。
第3方Cookie
網站監測代碼在發起請求時，能創建 Domain 不同于當前站點的 Cookie，也就是第3方 Cookie，它一般用于追蹤用戶在不同站點的訪問行為。
以百度統計為例，只要你的站點部署了百度統計代碼，就能看到這個名為 ” HMACCOUNT_BFESS” 的第3方 Cookie，它看起來就是這樣的字符串：
這時右鍵選中 Cookie，選擇 ”Show Requests With This Cookie”：
打開了 Network，點擊第1個請求，拉到 Request Headers 會發現有2個 Set-Cookie，說明這個第3方 Cookie 這是由服務器端設置的：
第1個的末尾標記了黃色符號，代表這個 Cookie 沒有創建成功，因為創建時沒有設置 SameSite 和 Secure。第2個 Cookie，也就是 ”HMACCOUNT_BFESS”，因為同時滿足 SameSite=None 和 Secure=Ture 這兩個條件，Cookie 能被創建。
SameSite 屬性是什么？這是一個限制第3方 Cookie 創建、讀寫的屬性。從 Chrome v80 開始，對第3方 Cookie 的限制就嚴格了許多。現在想要創建第3方 Cookie，需要滿足以下條件：
①通過 Https 協議
②設置 SameSite 為 None
③設置 Secure 為 True
當一個 Cookie 作為第3方 Cookie 時，它能不能被讀寫，由 SameSite 決定。當然這個讀寫，還是必須先取決于 Cookie 的 Domain，否則就成跨域了。SameSite 有以下3種值：
①Strict
假如 Cookie 的 SameSite為Strict，則當它作為第3方 Cookie 時會被完全禁止讀取，盡管你可能在 DevTools 的 Application 面板還能看到這個 Cookie。
②Lax
假如 Cookie 的 SameSite 為 Lax，那么當請求為以下類型，才能讀寫這個第3方 Cookie：
Lax也是Chrome的默認設置。
③None
想要關閉 SameSite 屬性，可以設置第3方 Cookie 的 SameSite 屬性為 None，要想讀取 Cookie 同時還必須設置 Secure 為 True。這也是為什么我們看到百度統計的 Cookie 設置了 SameSite=None 和 Secure 屬性。
第1方 Cookie 和第3方 Cookie 在網站監測都很重要，如今 Chrome 對第3方 Cookie 的限制越來越強，為網站監測工具讀寫第3方 Cookie 增加了一定難度。如何在合理追蹤用戶行為的同時保護用戶隱私，這是一個值得全行業探討的主題。
更多閱讀推薦
下一代 IDE：Eclipse Che 究竟有什么奧秘？
竊隱私、放高利貸，輸入法的騷操作真不少！
進入編譯器后，一個函數經歷了什么？
程序員離職后收到原公司 2400 元，被告違反競業協議賠 18 萬
5年5億美金，華為昇騰如何爭奪AI開發者？
總結
以上是生活随笔為你收集整理的如何用Chrome读懂网站监测Cookie的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 30岁，真的是程序员迈不过去的坎吗？
- 下一篇： CPU：别再拿我当搬砖工！