【Web技术】"Same-site" 和 "same-origin"

“同一网站”【"Same-site" 】和“同源”【"same-origin"】是经常被引用但经常被误解的术语。例如，它们用于页面转换、fetch（）请求、cookie、打开弹出窗口、嵌入资源和iframe的上下文。本页解释了它们是什么以及它们之间的区别。

Origin

起源的结构。

“起源”是一个方案（也称为协议，例如HTTP或HTTPS）、主机名和端口（如果指定）的组合。例如，给定的URLhttps://www.example.com:443/foo，“原点”是https://www.example.com:443.

“同源”和“跨源”【"Same-origin" and "cross-origin"】

具有相同方案、主机名和端口组合的网站被视为“同源”网站。其他一切都被认为是“交叉起源”。

Origin A	Origin B	"Same-origin" or "cross-origin"?
https://www.example.com:443	https://www.evil.com:443	Cross-origin: different domains
	https://example.com:443	Cross-origin: different subdomains
	https://login.example.com:443	Cross-origin: different subdomains
	http://www.example.com:443	Cross-origin: different schemes
	https://www.example.com:80	Cross-origin: different ports
	https://www.example.com:443	Same-origin: exact match
	https://www.example.com	Same-origin: implicit port number (443) matches

站点 【site】

 
要点：“站点”的规范包括方案。自2019年末以来，情况一直如此。在“站点”包含方案之前，通常使用“有方案的同一站点”【"schemeful same-site】。现在，“有计划的相同站点”被称为“相同站点”，而相同站点的旧形式被称为无方案的相同网站【schemeless same-site.】。有关更多信息，请参阅“无方案的同一站点”【"Schemeless same-site".】。

 

URL中组成网站的部分。

顶级域（TLD）（如.com和.org）列在根区域数据库中。在上一个
例如，“site”是该方案、TLD和它之前的域部分（我们称之为TLD+1）的组合。例如，给定的URL https://www.example.com:443/foo，“站点”是https://example.com.

公共后缀列表和eTLD

对于包含.co.jp或.github.io等元素的域，仅使用.jp或.io并不足以识别“站点”。无法通过算法确定特定TLD的可注册域级别。为了帮助实现这一点，公共后缀列表定义了一个公共后缀列表，也称为有效TLD（eTLD）。eTLD的列表保存在publicsuffix.org/list上。

要识别包含eTLD的域的“站点”部分，请应用与.com示例相同的做法https://www.project.github.io:443/foo例如，该方案是https，eTLD是.githhub.io，eTLD+1是project.github.io，因此https://project.github.io被视为此URL的“站点”。

站点（eTLD+1）

带有eTLD的URL的部分。

“同一站点”和“跨站点”

具有相同方案和相同eTLD+1的网站被视为“相同网站”。具有不同方案或不同eTLD+1的网站是“跨站点”的。

Origin A	Origin B	"Same-site" or "cross-site"?
https://www.example.com:443	https://www.evil.com:443	Cross-site: different domains
	https://login.example.com:443	Same-site: different subdomains don't matter
	http://www.example.com:443	Cross-site: different schemes
	https://www.example.com:80	Same-site: different ports don't matter
	https://www.example.com:443	Same-site: exact match
	https://www.example.com	Same-site: ports don't matter

“无计划的同一网站”【"Schemeless same-site"】

无方案的同一站点
“同一站点”的定义更改为将URL方案作为站点的一部分，以防止HTTP被用作弱通道。没有方案比较的“相同站点”的旧概念现在被称为“无方案的相同站点”。例如http://www.example.com和https://www.example.com被认为是无方案的相同站点，但不是相同站点，因为只有eTLD+1部分很重要，而该方案没有被考虑。

Origin A	Origin B	"Schemeless same-site" or "cross-site"?
https://www.example.com:443	https://www.evil.com:443	Cross-site: different domains
	https://login.example.com:443	Schemeless same-site: different subdomains don't matter
	http://www.example.com:443	Schemeless same-site: different schemes don't matter
	https://www.example.com:80	Schemeless same-site: different ports don't matter
	https://www.example.com:443	Schemeless same-site: exact match
	https://www.example.com	Schemeless same-site: ports don't matter

如何检查请求是“同一站点”、“同源”还是“跨站点”

浏览器支持

所有现代浏览器都使用Sec Fetch Site HTTP标头【Sec-Fetch-Site HTTP header】发送请求。标头具有以下值之一：

• cross-site
• same-site (refers to schemeful same-site)
• same-origin
• none

您可以检查Sec Fetch Site的值，以确定请求是同一站点、同源还是跨站点。

您可以合理地信任Sec Fetch Site标头的值，因为：

• HTTP headers starting with Sec- can't be modified by JavaScript
• 浏览器总是设置这些标题。

关键点：即使随机的HTTP客户端向服务器发送一个被操纵的Sec Fetch Site标头值，也不会因破坏同源策略而损害用户或浏览器。