原文地址：https://alphahinex.github.io/2021/05/30/same-origin-and-same-site-of-cookie/
description: "Cookie 中的同源，等价于同站？！"
date: 2021.05.30 10:34
categories:
- Web
tags: [Web, HTML]
keywords: origin, site, same origin, cross origin, same site, corss site, CSRF, SOP, port, cookie
存储在浏览器中的数据，如 localStorage 和 IndexedDB，是以 源（origin） 进行分割的。每个源都拥有自己单独的存储空间，一个源中的 JavaScript 脚本不能对属于其它源的数据进行读写操作，即所谓的 同源策略（SOP）。
Cookie 的同源
然而 Cookie 在受同源策略约束时，使用不同的源的定义方式。
通常来讲：
而根据 Cookie 的现行标准规范 HTTP State Management Mechanism (rfc6265) ：
即，相同 host，不同端口的服务之间，cookie 是可以共享的！
另外：
由上可知，Cookie 不提供根据 scheme 和 port 的隔离性，也就是说：
Cookie 中同源的定义，等价于不考虑 scheme 的同站（schemelessly same site）定义!
默认情况下，Cookie 可以在 eTLD + 1 相同的站点间进行共享！
另外，服务端可以通过响应的 Set-Cookie Header，对 Cookie 的可用性进行设定，相关的属性包括 Domain、Path、Secure 等。
比如通过 Path 属性，可以指定允许获得 Cookie 的 URL 路径前缀。
Cookie 的同站
现行的 rfc6265 标准是 2011 年 4 月开始实行的，在后续的 rfc6265bis 提案的 02 版本中，在 Set-Cookie 的响应头中增加了 SameSite 属性，用来约束对 Cookie 的跨站访问行为，以提升安全性，降低 CSRF 攻击的风险。
该提案的最新版本为 draft-ietf-httpbis-rfc6265bis-07（将于 2021 年 6 月 10 日到期），此版本中 SameSite 属性有三个值：
- Lax：通常情况下不会在跨站请求中携带 Cookie，但用户主动导航至外站时，会携带用户之前访问此外站的 Cookie。在
SameSite属性未被显示设定时，将按照SameSite=Lax进行对携带 Cookie 的约束（07 版提案之前，未设定SameSite等价于SameSite=None）。 - Strict：跨站请求时不会携带 Cookie。
- None：同站和跨站的请求都会携带 Cookie。当设置了
SameSite=None时，Cookie 的Secure属性也必须被同时设定（即此时 Cookie 只能通过 https 协议发送），否则 Cookie 会被拦截。
在此版本提案中，对于同站的定义增加了 scheme 部分，即与最新的 HTML 标准一致：scheme 和 eTLD + 1 同时相同，才能够认为是同站（same site）。
