小cookie，大智慧
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
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]
Cookie標頭的內容是鍵值對(鍵值對才是具業務含義的cookie)；同名cookie覆蓋原鍵值，不同名cookie會追加到鍵值對。
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; X-BAT-FullTicketId=TGT-969171-******
除了服務端響應時使用Set-Cookie標頭種植cookie，瀏覽器JavaScript也可以種植cookie
cookie的種植面積
Domain和Path屬性定義了cookie的寫入範圍：哪些url的請求可以攜帶該cookie。
Domain指定哪些host能被種植該cookie，如果沒有指定，預設是當前document location所在的host，不包含子域；如果指定了Domain，那麼包括子域。
例如設定了Domain=bat.com， 那麼類似於developer.bat.com下的url請求都會種下該cookie.
- Path 指定能攜帶該cookie的具體url。 "/" 是目錄分隔符，會匹配子目錄.
例如設定了Path =/doc，下面的目錄都會被匹配. - /docs - /docs/web/ - /docs/web/http
cookie的有效時長
一般情況下瀏覽器關閉，cookie失效；
可通過設定特定的Expires或者Max-Age為cookie設定相對較長的有效時間。
Set-Cookie: id= a2faw; Expires=Wed,21 Oct 2015 07:12 GMT
當設定了過期時間，這個設定的時間是相對於瀏覽器而言，而非伺服器。
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）的攻擊。
如：訪問會話在瀏覽器留置的認證cookie就沒有必要暴露給JavaScript，可對其設定HttpOnly指令 Set-Cookie: X-BAT-FullTicketId=TGT-969171-******; Expires=Wed, 21 Oct 2020 07:28:00 GMT; Secure; HttpOnly
哪些瀏覽器請求能合法攜帶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
Set-Cookie: X-bat-FullTicketId=TGT-178876-em4xx0faD1c4pbt*********k5Z0vN4uPOoEBWfGIP6l-bat-xxxxooo; path=/; samesite=none; httponly
有如下列舉值：
-
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大類，關注HTTP
Sec-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