Cookie 機制完全解析

HTTP 協議是無狀態的一個用戶第二次請求和一個新用戶第一次請求服務端是識別不出來的，cookie 是爲了讓服務端記住客戶端而被設計的。

Cookie 是存儲在用戶 web 瀏覽器中的小塊數據一般不超過 4k，它一般用於存儲用戶身份信息。
Cookie 是由服務端設置在瀏覽器上的
Cookie 是由瀏覽器管理的並且隨着 http 請求自動發送的。
Cookie 在服務端配置允許的前提下可以使用js訪問操作cookie。

既然 cookie 是一種存儲方式用來存儲用戶身份我們同樣可以使用其他的存儲方式替代 cookie 這是完全可以的只是需要我們自己發送和維護畢竟 cookie 是瀏覽器自動發送和清理的。

name&value

屬性名和屬性值 cookie 中的內容信息

domain&path

設置了cookie的作用範圍。

Domain：指定了 Cookie 發送的主機名, 只能設置範圍小於等於自己的域名範圍。假如沒有指定，那麼默認值爲當前文檔訪問地址中的主機部分（但是不包含子域名）。
path：指定一個 URL 路徑，只有當路徑匹配時，纔會向服務器發送 Cookie。例如設置 “/” 這此域下所有路徑都可以攜帶 cookie。

Expires&Max-Age

設置 cookie 有效期。Expires 和 Max-Age 都存在，Max-Age 優先級更高。

Expires：設置 Cookie 的過期時間。如果不設置，Cookie 會在瀏覽器關閉時自動失效，稱爲會話 Cookie（Session Cookie）。Expires 使用的是具體的日期和時間（例如：Sat, 31 Dec 2022 23:59:59 GMT）。
Max-Age：設置 Cookie 在多少秒後過期。與 Expires 相比，Max-Age 是相對於當前時間的持續時間，更加靈活。max-Age > 0, 瀏覽器會將其持久化，即寫到對應的 Cookie 文件中。當 max-Age < 0，則表示該 Cookie 只是一個會話性 Cookie。當 max-Age = 0 時，則會立即刪除這個 Cookie。

Secure

標記該屬性的 Cookie 只應通過被 HTTPS 協議加密過的請求發送給服務端。這有助於保護數據在互聯網上傳輸過程中不被竊取。

HttpOnly

此屬性用來幫助防止跨站腳本攻擊（XSS），因爲標記爲 HttpOnly 的 Cookie 無法通過 JavaScript 的 Document.cookie API 訪問。這意味着即使系統有 XSS 漏洞，Cookie 也不會被盜取。

Size 與 Priority

Cookie 的大小一般爲 4KB，當超出這個範圍時會移除舊的 Cookie。移除時按照優先級由低到高刪除。

SameSite

SameSite 屬性可以讓 Cookie 在跨站請求時不會被髮送，從而可以阻止跨站請求僞造攻擊（CSRF）。

Strict：Cookie 不會隨着來自第三方的請求被髮送
Lax：在一些第三方請求場景中發送，例如通過a標籤鏈接點擊到其他站點時...
None：不做限制即使是來自第三方的請求，也會發送 Cookie，需要配合Secure屬性一起使用。

第三方 cookie：非當前域名下的服務器設置的 cookie。例如上圖中當前網頁訪問的是a.test.com網站, 請求了a.example.com的圖片資源，a.example.com即爲第三方。

SameSite 改變的影響

在 Chrome 80+ 版本中，SameSite 的默認屬性是 SameSite=Lax，當 Cookie 沒有設置 SameSite 屬性時，將會視作 Lax 。如果想要指定 Cookies 在同站、跨站請求都被髮送，那麼需要明確指定 SameSite 爲 None。具有 SameSite=None 的 Cookie 也必須標記爲安全並通過 HTTPS 傳送。

同源 (Same-Origin)& 同站 (Same-Site)

Same-Origin

協議 (http/https)+ 主機 + 端口三者完全保持一致。
例如https://juejin.cn/post/7338284106797088809#heading-9和https://juejin.cn/post/7355063847382810635符合同源標準。

Cross-Origin

Same-Origin 規則中任意不一致即跨域具體參考瀏覽器: 安全策略 [1]

Same-Site

兩個 URL 的 eTLD+1 相同即可，不需要考慮協議和端口。
eTLD 表示有效頂級域名，註冊於 Mozilla 維護的公共後綴列表（Public Suffix List）中，例如，.com、.co.uk、.github.io 等。

eTLD+1 表示，有效頂級域名 + 二級域名。
例如：
test.com和a.test.com同站
test.com和example.com跨站

總結

web 中任何請求都受到同源限制，cookie 在此基礎上還會受到同站策略限制 (samesite 指定)。
跨站一定跨域跨域不一定跨站
ajax 跨域請求一般有兩個問題請求能否發出去 cookie 能否攜帶上。

通過 CORS 解決

服務器端配置：在服務器端設置響應頭 Access-Control-Allow-Credentials 爲 true，並且 Access-Control-Allow-Origin 不能爲 *，必須是請求方的具體源，如 example.com。[2]

客戶端配置：發起請求時，設置 credentials 爲 include 確保請求會攜帶 Cookie。

通過代理服務器解決

如果不是我們自己業務的服務端無法配置更改可以通過代理轉發的方案。

設置 samesite:none

設置跨站可以傳遞 cookie 需要配合 Secure 一起使用。

由主域直接設立和訪問，不受第三方 Cookie 限制的影響

代理服務器轉發

如同上面的方案一樣這個情況也同樣適用

使用其他存儲方案

cookie 的作用是存儲用戶標識讓服務端知道是誰在請求我們完全可以使用其他的存儲方式例如 localStorage.

follow 瀏覽器標準

例如Partitioned屬性設置 cookie 分區存儲。它的作用是使 第三方Cookie 與 第一方站點 相綁定，通過將第三方 Cookie 的讀取和寫入操作限制在創建它們的相同網站的上下文中，來增強用戶隱私。

分區前 cookie 存儲

因爲a.test.com和a.example.com都使用了a.3rd.com的資源。a.3rd.com可以在請求時設置 cookie。這樣當同一個用戶在兩個網站上活動時可以被a.3rd.com識別到，造成隱私泄露...

分區後 cookie 存儲 因爲 cookie 的存儲方式變了用戶在a.test.com瀏覽時 a.3rd.com設置的 cookie 包含了當前的上下文。

當用戶在a.example.com訪問時因爲[a.test.com,a.3rd.com]這個 cookie 無法被訪問到不會被自動發送給第三方服務器阻止了第三方的信息採集, 增強了用戶的隱私保護...

目的不同：跨域請求默認不攜帶 Cookie 主要是出於安全考慮，防止跨站點請求僞造等攻擊；禁止第三方 Cookie 主要是出於隱私保護考慮，防止用戶跨網站被追蹤。
操作層面不同：跨域 Cookie 的發送需要通過適當的服務器和客戶端配置來實現；第三方 Cookie 的禁用是由瀏覽器控制，影響所有第三方來源的 Cookie。

這兩者雖然都涉及到 Cookie 和瀏覽器的策略，但它們關注的重點、解決的問題和需要的配置都有所不同。

作者：某某某人

原文：https://juejin.cn/post/7360976761838960640

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CfZOtMtbd1tq4__oBp7VqA

cookie 的背景

cookie 是一種存儲方式

cookie 的關鍵屬性