出處：https://www.cnblogs.com/JulianHuang/p/12341471.html
創作不易，在滿足創作共用版權協議的基礎上可以轉載，但請以超鏈接形式註明出處。
為了方便閱讀，微信公眾號已按分類排版，後續的文章將在移動端首發，想學習雲原生相關知識，請關注我。
Cookie是什麼？cookies是你訪問網站時創建的數據片段文件，通過保存瀏覽信息，它們使你的在線體驗更加輕鬆。使用cookies，可以使你保持在線登錄狀態，記錄你的站點偏好，併為你提供本地化支持。
First-party cookies or Third-party cookies
第一方cookie由你訪問的站點創建。該站點指的是地址欄顯示的站點； 第三方cookie是由其他站點創建的。這些站點擁有你當前訪問的網頁上部分資源，如廣告或圖像。
第一方/第三方cookie不是絕對的標籤，而是相對於用戶的上下文，同一cookie可以是第一方也可以是第三方，這取決於用戶當時所在的網站。
為什麼要提強調第三方cookie，這與下面的cookie的SameSite策略密切相關。
cookie的常規使用方式
web服務端發送給瀏覽器的cookie，瀏覽器會存儲並在下次請求原服務器的時候回發cookie。
在HTTP請求模型中以標頭的形式體現：Response中Set-Cookie標頭種植cookie；Request Cookie標頭攜帶(該請求允許攜帶的)cookies
<code>HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: X-BAT-FullTicketId=TGT-969171-******; path=/; samesite=none; httponly
[page content]/<code>
Cookie標頭的內容是鍵值對(鍵值對才是具業務含義的cookie)；同名cookie覆蓋原鍵值，不同名cookie會追加到鍵值對。
<code>GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; X-BAT-FullTicketId=TGT-969171-******/<code>
除了服務端響應時使用Set-Cookie標頭種植cookie，瀏覽器JavaScript也可以種植cookie
cookie的種植面積
Domain和Path屬性定義了cookie的寫入範圍：哪些url的請求可以攜帶該cookie。
- Domain指定哪些host能被種植該cookie，如果沒有指定，默認是當前document location所在的host，不包含子域；如果指定了Domain，那麼包括子域。
<code>例如設置了Domain=bat.com， 那麼類似於developer.bat.com下的url請求都會種下該cookie.
/<code>
- Path 指定能攜帶該cookie的具體url。 "/" 是目錄分隔符，會匹配子目錄.
<code> 例如設置了Path =/doc，下面的目錄都會被匹配.
- /docs
- /docs/web/
- /docs/web/http/<code>
cookie的有效時長
一般情況下瀏覽器關閉，cookie失效；可通過設置特定的Expires或者Max-Age為cookie設置相對較長的有效時間。
<code> Set-Cookie: id= a2faw; Expires=Wed,21 Oct 2015 07:12 GMT/<code>
當設置了過期時間，這個設置的時間是相對於瀏覽器而言，而非服務器。
cookie與web安全息息相關
因為cookie是站點私有片段數據，與web上各種攻擊密切相關，如XSS,CSRF.
根據W3c的操作規範，種植cookie時可通過某些屬性限制cookie的使用方式。
發送cookie的物理安全
Secure指定了發送cookie的物理安全：要求以HTTPS形式回發cookie。 Chrome52+、Firefox52+已經支持Secure指令，再使用http請求已經不會攜帶Secure cookie。
即便是Secure指令， 敏感信息也不要放在cookie中， 因為他們天生就不安全，https並不能提供足夠有效的安全防護。
誰能訪問cookie？
web上能訪問cookie的物件有兩種：
- 瀏覽器請求
- JavaScript
HttpOnly指示cookie將不能通過JavaScript的document.cookie編程接口訪問，這樣可以緩解對跨站點腳本（XSS）的攻擊。
<code>如：訪問會話在瀏覽器留置的認證cookie就沒有必要暴露給JavaScript，可對其設置HttpOnly指令
Set-Cookie: X-BAT-FullTicketId=TGT-969171-******; Expires=Wed, 21 Oct 2020 07:28:00 GMT; Secure; HttpOnly/<code>
哪些瀏覽器請求能合法攜帶cookie？
首先科普一下重要的web HTTP知識：對頁面資源的請求，依據請求發起者的源Origin與資源的源Origin的相等關係，被劃分為4類。
Http請求中Sec-Fetch-Site標頭指示了這個屬性：
Sec-Fetch-Site描述cross-site請求的發起源與資源源完全不一樣same-origin請求的發起源與資源源完全一樣same-site請求的發起源與資源源不完全一樣，位於同一頂級域名下二級域名none
Q1. 源Origin、站Site、域Domain傻傻分不清清楚？
看圖! 觀察www.cnblog.com任意一篇博文的network，看動圖！
在博客頁面www.cnblog.com/xxx/p/110.htm上發起的
- www.cnblogs.com/xxx/ajax/Follow/GetFollowStatus.aspx是same-origin請求
- blog-static.cnblogs.com/files/shwee/clock.js是same-site請求
- www.google-analytics.com/r/collect?v=1&_v=j81&a=38982783&t=pageview&_s=1是cross-site請求
Q2. 聊cookie為什麼要提到給請求分類的Sec-Fetch-Site標頭?
答：B站頁面在請求A站資源時能否攜帶A站cookie（第三方cookie）不僅是一個道德問題；技術上還牽涉web安全(CSRF)。
針對以上的請求類型，瀏覽器針對cookie有SameSite屬性，提供針對跨站點請求偽造攻擊（CSRF）的保護。
在服務端Set-Cookie種植cookie時，SmmeSite屬性值可指示瀏覽器是否可在後續的“同一站點”或“跨站點”請求中攜帶這些cookie
<code>Set-Cookie: X-bat-FullTicketId=TGT-178876-em4xx0faD1c4pbt*********k5Z0vN4uPOoEBWfGIP6l-bat-xxxxooo; path=/; samesite=none; httponly/<code>
有如下枚舉值：
- Lax ： 對同源、頂級域的請求才可以攜帶cookie （等價於same-site）
- Strict: 對同源請求才可以使攜帶cookie （等價於same-origin）
- None： 對於cookie的使用無限制，隨便使用
最新的IEEF cookie SameSite策略：
1. 敦促瀏覽器版本遷移，使cookie的SameSite默認= Lax
2. 如果需要跨域發送cookie，請使用None枚舉值選擇無SameSite限制, None指令需要搭配Secure指令
Tip： None枚舉值是標準新增枚舉值，一些舊瀏覽器不識別這個枚舉值，可能導致一些問題.
總之，IEEF配合瀏覽器給cookie的存取、傳輸規定了一套完整的策略，環環相扣，促進了web上cookie的平衡應用。
總結本文輸出
- 第一方cookie vs 第三方cookie的認定： 取決於訪客所處的上下文
- cookie的常規用法，大家耳熟能詳
- 根據源Origin、站Site、域Domain，請求被劃分為4大類，關注HTTPSec-Fetch-Site標頭
- 服務器在種植cookie時，可對cookie設置SameSite屬性，故SameSite作用對象是cookie
- SameSite屬性決定了後續的跨域/跨站請求是否可以攜帶B站cookie，緩解了CSRF攻擊
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site
- https://web.dev/samesite-cookies-explained
閱讀更多 大數據與雲原生 的文章
