理解“同站”和“同源”
“同站”和“同源”是两个常用但也常被误解的术语。例如，在页面转换、fetch() 请求、Cookie、打开弹出窗口、嵌入资源和 iframe 的上下文中都会使用这两个术语。
来源 #
“来源 (Origin)”就是方案（也称为协议，例如 HTTP 或 HTTPS）、主机名和端口（如果指定）的组合。例如，假设 URL 是 https://www.example.com:443/foo ，则“来源”为 https://www.example.com:443。
“同源”和“跨源” {：#same-origin-and-cross-origin } #
方案、主机名和端口均相同的组合的网站视为“同源”，否则视为“跨源”。
站点 #
顶级域 (TLD)，例如 .com 和 .org 列在根区数据库中。在上面的示例中，“站点”是 TLD 与它之前的域部分的组合。例如，假设 URL 是 https://www.example.com:443/foo ，则“站点”为 example.com。
但是，对于 .co.jp 或 .github.io 等域，仅使用 .jp 或 .io 的 TLD 不足以识别“站点”。同时，无法通过算法确定特定 TLD 的可注册域的级别。这就是创建“有效 TLD”(eTLD) 列表的原因。这些域在公共后缀列表中进行定义。eTLD 列表的维护网站是 publicsuffix.org/list。
完整站点名称为 eTLD+1。例如，假设 URL 为 https://my-project.github.io，则 eTLD 为 .github.io，而 eTLD+1 则为 my-project.github.io，这就是一个“站点”。换句话说，eTLD+1 是有效的 TLD 加上它前面的域部分。
“同站”和“跨站”{：#same-site-cross-site } #
eTLD+1 相同的网站被视为“同站”。eTLD+1 不同的网站则被视为“跨站”。
“有方案同站” #
“同站”的定义正在演变为将 URL 方案视为站点的一部分，从而防止将 HTTP 用作弱通道。由于浏览器转变为这种解释，因此，当引述旧定义时，您可能会看到“无方案同站”之类的引用，而“有方案同站”则是更严格的定义。在这种情况下，http://www.example.com 和 https://www.example.com 被视为跨站，因为方案不匹配。
如何检查请求是“同站”、“同源”还是“跨站” #
Chrome 将请求与 Sec-Fetch-Site HTTP 标头一起发送。截至 2020 年 4 月，没有其他浏览器支持 Sec-Fetch-Site。这是更大的获取元数据请求标头 (Fetch Metadata Request Headers) 提案的一部分。该标头的值为以下之一：
cross-sitesame-sitesame-originnone
通过检查 Sec-Fetch-Site 的值，您可以确定请求是“同站”、“同源”还是“跨站”（“有方案同站”不是在 Sec-Fetch-Site 中获取）。