SameSite 与第三方 Cookie：现代浏览器的隐私防线

在 Web 诞生后的前二十年里，Cookie 几乎是“自由流动”的。广告网络、分析脚本、社交插件可以轻易地在任意站点上读写 Cookie，跨站追踪用户行为。直到近几年，浏览器厂商才开始真正收紧缰绳。其中最具代表性的两项技术变革，就是 SameSite Cookie 属性的默认强化，以及第三方 Cookie 的逐步淘汰。它们共同构成了现代浏览器隐私防线的核心。

为什么 Cookie 会成为追踪的温床？

HTTP 协议本身是无状态的。为了记住用户登录状态、购物车内容或语言偏好，网站使用 Cookie 在浏览器端存储小型数据。问题在于，浏览器在发送 Cookie 时，默认并不区分“第一方”还是“第三方”上下文。

假设你访问 news.com，页面里嵌入了一个来自 ads.net 的图片或脚本。浏览器在请求 ads.net 资源时，会带上 ads.net 之前种下的 Cookie。这样一来，ads.net 就能在 news.com 上识别出你，并记录“这个用户看过新闻”。当你再访问 shop.com，同样嵌入 ads.net 的代码，它又能识别出同一个你。于是，跨站行为画像就建立起来了。

这就是第三方 Cookie 的追踪原理：不是通过技术漏洞，而是通过浏览器默认允许的跨站请求携带 Cookie 机制。

SameSite：给 Cookie 加上“同站”约束

SameSite 是 Cookie 的一个属性，用来控制浏览器在跨站请求中是否发送该 Cookie。它有三个取值：

• Strict：最严格。只有当前页面 URL 与 Cookie 所属站点完全一致时，才会发送 Cookie。从外部站点跳转过来时，即使用户已登录，第一次请求也不会带上 Cookie。
• Lax：默认值（现代浏览器）。允许在顶级导航（比如点击链接跳转）时发送 Cookie，但禁止在 iframe、AJAX、图片等子资源请求中跨站发送。
• None：显式允许跨站发送，但必须同时设置 Secure 属性（即只能通过 HTTPS 发送）。

关键变化发生在 2020 年前后。Chrome、Firefox、Edge 等浏览器陆续将未设置 SameSite 的 Cookie 默认视为 Lax。这意味着，过去大量依赖跨站 Cookie 的广告、分析、嵌入内容，如果不显式声明 SameSite=None; Secure，就会在跨站场景中失效。

这一改动直接削弱了第三方 Cookie 的可用性。很多追踪脚本发现，自己种下的 Cookie 在别的站点上根本收不到，因为浏览器不再默认放行。

第三方 Cookie 的逐步退场

SameSite 默认 Lax 只是第一步。更彻底的举措是直接阻止第三方 Cookie。

• Safari 从 ITP（Intelligent Tracking Prevention）开始，早已默认阻止第三方 Cookie，并引入存储访问 API 等替代方案。
• Firefox 的“增强跟踪保护”默认拦截已知追踪器的跨站 Cookie。
• Chrome 虽然时间表多次调整，但方向明确：逐步淘汰第三方 Cookie，转向 Privacy Sandbox 系列 API（如 Topics、Attribution Reporting 等）。

对开发者而言，这意味着不能再假设“用户在 A 站登录，B 站就能通过第三方 Cookie 认出他”。跨站身份识别必须依赖第一方存储、服务端会话或显式的用户授权。

对 Web 开发的实际影响

1. 嵌入内容与 SSO 登录

很多单点登录（SSO）流程依赖跨站 iframe 或重定向来传递会话。SameSite=Lax 默认值下，iframe 内的跨站请求不会携带 Cookie，导致登录态无法维持。解决办法通常是：

• 将关键 Cookie 设为 SameSite=None; Secure，但需评估 CSRF 风险。
• 改用顶层重定向完成认证，而非 iframe。
• 采用 OAuth 2.0 授权码 + PKCE 等不依赖第三方 Cookie 的流程。

2. 广告与数据分析

依赖第三方 Cookie 的归因模型、频次控制、受众定向都会受到冲击。替代方案包括：

• 第一方数据：站点自己收集的行为数据，通过服务端与广告平台对接。
• 隐私沙盒 API：如 Chrome 的 Topics API 提供粗粒度兴趣标签，而非个体追踪。
• 服务端转化 API：由站点后端直接向广告平台发送转化事件，不依赖浏览器 Cookie。

3. CSRF 防护

SameSite=Lax 本身就能缓解大部分 CSRF 攻击，因为跨站 POST 请求不会自动带上会话 Cookie。但开发者仍需注意：

• 对敏感操作使用 SameSite=Strict 或额外 CSRF Token。
• 不要为了兼容旧逻辑而盲目把所有 Cookie 设为 SameSite=None。

隐私防线背后的权衡

SameSite 和第三方 Cookie 限制确实提升了隐私保护，但也带来了副作用：

• 小站点和独立开发者可能更难接入广告或分析服务，因为大平台有资源自建第一方数据管道。
• 某些合法跨站功能（如嵌入式支付、地图、评论系统）需要重新设计。
• 指纹识别可能部分取代 Cookie 追踪，因为浏览器指纹不依赖客户端存储，更难被 SameSite 约束。

因此，现代隐私防线不是单一技术，而是一套组合：SameSite 约束 Cookie 的跨站发送，第三方 Cookie 阻止跨站识别，再配合存储分区、指纹缓解、隐私沙盒 API，形成多层防御。

开发者应该怎么做

1. 审计现有 Cookie：列出所有 Cookie，标注用途、是否跨站、当前 SameSite 设置。
2. 显式声明 SameSite：不要依赖浏览器默认值，根据业务需求明确设置 Lax、Strict 或 None。
3. 减少对第三方 Cookie 的依赖：将关键状态迁移到第一方存储或服务端会话。
4. 测试跨站场景：在 Chrome、Safari、Firefox 上验证登录、支付、嵌入内容是否正常。
5. 关注 Privacy Sandbox：如果业务涉及广告或归因，尽早评估替代 API 的可行性。

结语

SameSite 与第三方 Cookie 的变革，标志着 Web 从“默认开放”走向“默认保护”。对用户而言，这是隐私防线的实质性加固；对开发者而言，这是一次必须适应的架构调整。理解这些机制的原理与边界，才能在不牺牲功能的前提下，构建更尊重隐私的 Web 应用。

未经允许不得转载：任鹏个人博客 » SameSite 与第三方 Cookie：现代浏览器的隐私防线