共计 4837 个字符，预计需要花费 13 分钟才能阅读完成。
本文首发国内开源代码托管平台 Gitee
文章地址：
https://gitee.com/gooder4j/co…
仓库会集英语 meme 公众号【Yopen】和技术公众号【鹏哥儿的 Echo】相干文章
感觉不错的话，你的 star 是对我最大的反对！
鹏哥儿最近从新回顾了一下 XSS（Cross Site Script）和 CSRF（Cross Site Request Forgery），又分割到 cookie 的同源策略（Same-origin policy），发现自己对 源（origin）和 站（site）有些混同，所以找了篇优良的文章：Understanding “same-site” and “same-origin”，来对两者加以辨别。
源
“Origin” is a combination of a scheme (also known as the protocol, for example HTTP or HTTPS), hostname, and port (if specified). For example, given a URL of https://www.example.com:443/foo , the “origin” is https://www.example.com:443.
“源”是 scheme（也被称为协定，例如 HTTP 和 HTTPS），主机域名和端口（如果有指定）的联合。例如，给定一个 URLhttps://www.example.com:443/foo，它的“源”是 https://www.example.com:443。
一条申请的外围局部就是这三局部：scheme+ 主机域名 + 端口，三者可能惟一标识通信方，这三局部的组成也被称为套接字（socket）。
下文 scheme 通通指例如 HTTP 或者 HTTPS 这样的协定。
同源和跨源
Websites that have the combination of the same scheme, hostname, and port are considered “same-origin”. Everything else is considered “cross-origin”.
雷同 scheme、主机域名和端口联合的网站被认为是“同源”，其余的被认为是“跨源”。
同源是最严格的，scheme、主机域名和端口必须都要雷同。
假如当初有源 A：https://www.example.com:443
大家能够遮住第 2 列，猜一猜源 B 和源 A 是属于同源还是跨源：
| 源 B | 答案 |
|---|---|
| https://www.evil.com:443 | 跨源，因为主机域名不雷同 |
| https://example.com:443 | 跨源，同上 |
| https://login.example.com:443 | 跨源，同上 |
| http://www.example.com:443 | 跨源，scheme 不雷同 |
| https://www.example.com:80 | 跨源，端口号不雷同 |
| https://www.example.com:443 | 同源，scheme，主机域名、端口号完全相同 |
| https://www.example.com | 同源，假如这条源 B 的默认端口号是 443 |
站
Top-level domains (TLDs) such as .com and .org are listed in the Root Zone Database. In the example above, “site” is the combination of the TLD and the part of the domain just before it. For example, given a URL of https://www.example.com:443/foo , the “site” is example.com.
根域服务器列出了例如.com 和.org 这样的 顶级域名 （Top-level domain，简称TLD）。在下面这个例子中， 站就是顶级域名 TLD 加上它之前的局部域名。例如，给定一个 URL 是 https://www.example.com:443/foo，那么它的“站”就是example.com。
站其实就是主机域名的限定子集：局部域名 + 顶级域名。
想要理解一个域名是不是顶级域名，能够到这个网址去查看：https://www.iana.org/domains/…
However, for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the “site”. And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That’s why a list of “effective TLDs”(eTLDs) was created. These are defined in the Public Suffix List. The list of eTLDs is maintained at publicsuffix.org/list.
然鹅，对于例如.con.jp 或者.github.io，仅应用.jp 和.io 这样的顶级域名 TLD 来说，没方法准确标识一个“站”。并且对于一个特定的顶级域名 TLD，这里也没有算法去确定可注册域名的等级。这就是为什么一系列“无效顶级域名（effective TLD，简称 eTLD）”被创立进去。
域名也是分无效有效的，不过，个别记住个 .com 就行了，其余的去这个网站查一下就行了：https://publicsuffix.org/list/
The whole site name is known as the eTLD+1. For example, given a URL of https://my-project.github.io , the eTLD is .github.io and the eTLD+1 is my-project.github.io, which is considered a “site”. In other words, the eTLD+1 is the effective TLD and the part of the domain just before it.
整个站名被称为“eTLD+1”，例如，给定一个 URL：https://my-project.github.io，eTLD 是
.github.io，eTLD+ 1 是my-project.github.io，eTLD 被认为是一个“站”。换句话说，eTLD+ 1 是无效的 TLD 加上它之前的局部域名。
假如当初有源 A：https://www.example.com:443
大家同样能够遮住第 2 列，猜一猜源 B 和源 A 是属于 同站 还是 跨站：
| 源 B | 答案 |
|---|---|
| https://www.evil.com:443 | 跨站，局部域名不一样 |
| https://login.example.com:443 | 同站，eTLD+ 1 一样 |
| http://www.example.com:443 | 同站，同上 |
| https://www.example.com:80 | 同站，同上 |
| https://www.example.com:443 | 同站，同上 |
| https://www.example.com | 同站，同上 |
相比于同源，同站显得雷同更加宽容。
同协定同站
The definition of “same-site” is evolving to consider the URL scheme as part of the site in order to prevent HTTP being used as a weak channel. As browsers move to this interpretation you may see references to “scheme-less same-site” when referring to the older definition and “schemeful same-site” referring to the stricter definition. In that case, http://www.example.com and https://www.example.com are considered cross-site because the schemes don’t match.
“ 同站 ” 的定义逐步倒退，思考把 URL 的 scheme 纳为站的一部分，用于避免 HTTP 被作为弱隧道。当浏览器转向这种解释时，对于“scheme-less same-site”（不同协定同站）指向旧的定义，“schemeful same-site”（同协定同站）指向更严格的定义。在这样的例子中，http://www.example.com 和 https://www.example.com 被认为是跨站的，因为它们之间的 scheme 是不匹配的。
同协定同站也就是 scheme+(eTLD+1)，就能够认为他们同站。为什么要思考 scheme 呢，文中提到 HTTP 被利用做弱隧道，其实也就是说攻击者会利用不平安的 http 发动 CSRF 攻打一个 https 平安站点 ^[2]^。
假如当初有源 A：https://www.example.com:443
| 源 B | 答案 |
|---|---|
| https://www.evil.com:443 | 跨站 |
| https://login.example.com:443 | 同协定同站 |
| http://www.example.com:443 | 不同协定同站 |
| https://www.example.com:80 | 同协定同站 |
| https://www.example.com:443 | 同协定同站 |
| https://www.example.com | 同协定同站 |
如何查看一个申请是“同站”，“同源”，或者“跨站”
Chrome sends requests along with a Sec-Fetch-Site HTTP header. No other browsers support Sec-Fetch-Site as of April 2020. This is part of a larger Fetch Metadata Request Headers proposal. The header will have one of the following values:
cross-sitesame-sitesame-originnoneChrome 发送随同
Sec-Fetch-SiteHTTP 申请头的申请。其余浏览器截至 2020 年 4 月还没有反对Sec-Fetch-Site。这是 获取元数据申请头 提案更广的一部分。这个头部会有一个如下其中之一的值：
cross-sitesame-sitesame-originnone
在 chrome 上输出一个网址：https://juejin.cn/post/705343…，F1 轻易查看一条申请，在申请头上的确是能够看到这个sec-fetch-site。（没有 chrome 的小伙伴也能够用 Edge 浏览器:man_technologist:）
By examining the value of
Sec-Fetch-Site, you can determine if the request is “same-site“, “same-origin“, or “cross-site” (“schemeful-same-site” is not captured inSec-Fetch-Site).通过查看
Sec-Fetch-Site的值，你能够确定一个申请是否是“same-site”，“same-origin”，或者“cross-site”（“schemeful-same-site”不能被“Sec-Fetch-Site”捕捉）。
总结
源看三局部：
- scheme
- 主机域名
- 端口
站看两局部
- scheme
- 局部域名 + 无效顶级域名
REFERENCE
[1] https://web.dev/same-site-sam…,considered%20%22cross%2Dorigin%22.
[2] https://datatracker.ietf.org/…