同源与跨域场景下First-party Cookie判定及浏览器差异问询

场景说明 #

• (A) 我方拥有域名 testbuy.com 的网站；
• (B) 我方在 app.testbuy.com 部署了独立应用；
• (C) 我方在 cdnjs.com/testscript.js 托管了一段JavaScript脚本。

用户访问 testbuy.com 时，会下载上述脚本(C)，该脚本会向 app.testbuy.com(B) 发起POST请求，触发时机为页面加载或用户点击“购买”按钮时。首次请求时，app.testbuy.com(B) 会设置带有SameSite属性的Cookie，后续请求会自动携带该Cookie。

技术问题与解答 #

1. 尽管脚本来自非同源的cdnjs.com，该Cookie是否仍被视为First-party Cookie？ #

是。Cookie的第一方/第三方判定依据是设置Cookie的域与用户当前访问的主站域是否属于同一站点（Site，即eTLD+1相同），和发起请求的脚本所在域无关。app.testbuy.com 是 testbuy.com 的子域，两者eTLD+1都是testbuy.com，属于同一站点，因此该Cookie属于第一方Cookie。

2. 若将脚本托管在app.testbuy.com/js/testscript.js，Cookie的判定逻辑是否会改变？ #

不会改变。Cookie的归属判定只看设置它的域和当前主站域的站点关系，和脚本是否同源没有关联。只要app.testbuy.com和testbuy.com属于同一站点，无论脚本来自哪里，Cookie的第一方判定逻辑都保持一致。

3. 上述逻辑在Safari、Chrome、Firefox浏览器中的表现有何差异？ #

• Chrome：严格遵循W3C的SameSite标准，以eTLD+1作为站点判定依据。只要请求符合SameSite属性规则（比如SameSite=Lax时，用户交互触发的POST请求会携带Cookie；SameSite=None需搭配Secure属性），无论脚本是否跨域，同一站点的Cookie都会正常携带。默认SameSite属性为Lax。
• Firefox：逻辑与Chrome基本一致，同样以eTLD+1判定站点，对SameSite规则的处理和Chrome对齐。跨域脚本发起的同一站点请求，只要符合SameSite规则，Cookie就能正常被携带。
• Safari：除了SameSite标准外，还有专属的「智能跟踪预防（ITP）」机制。即使是同一站点的子域，若请求由跨域脚本发起，Safari可能会将该Cookie标记为第三方，甚至在部分场景下阻止携带（比如来自公共CDN的脚本）。另外，Safari对SameSite=None的支持必须搭配Secure属性，且在ITP的限制下，跨域脚本触发的请求携带Cookie的规则会更严格。

额外问题：关于远程资源脚本的内容适用范围 #

该内容主要针对跨域脚本场景，但其中涉及的SameSite Cookie基础携带规则也适用于同源脚本。不过核心的“远程资源”相关特殊处理（比如跨域脚本发起请求时的Cookie限制逻辑）是专为跨域脚本设计的，同源脚本发起的请求不存在这类额外限制，因此该内容的重点适用场景是跨域脚本，通用规则部分对同源脚本有参考价值。

内容的提问来源于stack exchange，提问作者infinite_loop