SameSite Cookie 配方

ChromeFirefoxEdge 等浏览器正在根据 IETF 提案“逐步改进 Cookie”更改其默认行为,以便:

  • 没有 SameSite 属性的 Cookie 会被视为 SameSite=Lax,这意味着默认行为是将 Cookie 限制为在第一方环境中使用。
  • 用于跨网站使用的 Cookie 必须指定 SameSite=None; Secure,才能纳入第三方环境。

如果您尚未更新第三方 Cookie 的属性,则应尽快更新,以免日后被屏蔽。

浏览器支持

  • Chrome:51.
  • Edge:16.
  • Firefox:60.
  • Safari:13.

来源

跨网站 Cookie 或第三方 Cookie 的用例

在许多常见的使用场景和模式中,都需要在第三方环境中发送 Cookie。如果您提供或依赖于其中一种用例,请确保您或提供商在更新其 Cookie,以确保服务正常运行。

<iframe> 中的内容

<iframe> 中显示的来自其他网站的内容属于第三方环境。标准用例包括:

  • 从其他网站分享的嵌入内容,例如视频、地图、代码示例和社交媒体帖子。
  • 来自外部服务(例如付款、日历、预订和预留功能)的微件。
  • 社交按钮或防欺诈服务等微件,可创建不太明显的<iframes>

此处 Cookie 的用途可能包括维护会话状态、存储常规偏好设置、启用统计信息,或为拥有现有账号的用户提供个性化内容等。

浏览器窗口示意图,其中嵌入内容的网址与网页的网址不匹配。
如果嵌入的内容与顶级浏览上下文不同,则属于第三方内容。

由于 Web 本身就是可组合项,因此 <iframes> 还用于嵌入在顶级或第一方环境中查看的内容。在 iframe 中显示的网站使用的所有 Cookie 都被视为第三方 Cookie。如果您要创建的网站需要其他网站嵌入,并且需要 Cookie 才能正常运行,您还需要确保这些网站已标记为可跨网站使用,或者在没有 Cookie 的情况下能够正常回退。

跨网站发送“不安全”请求

“不安全”听起来可能令人担心,但它是指任何可能意图更改状态的请求。在 Web 上,这主要指 POST 请求。标记为 SameSite=Lax 的 Cookie 会在安全的顶级导航中发送,例如点击链接前往其他网站。不过,使用 POST 向其他网站提交 <form> 等操作不会包含 Cookie。

请求从一个网页转移到另一个网页的示意图。
如果传入请求使用“安全”方法,则网页会发送 Cookie。

此模式适用于可将用户重定向到远程服务以执行某些操作,然后再返回的网站,例如重定向到第三方身份提供程序。在用户离开网站之前,系统会设置一个 Cookie,其中包含一个单次使用令牌,以便在返回请求时检查此令牌,以防范跨站请求伪造 (CSRF) 攻击。如果返回请求是通过 POST 发送的,您需要将 Cookie 标记为 SameSite=None; Secure

远程资源

网页上的任何远程资源(例如来自 <img> 代码或 <script> 代码的资源)都可能依赖于随请求发送的 Cookie。常见用例包括跟踪像素和个性化内容。

这也适用于使用 fetchXMLHttpRequest 从 JavaScript 发送的请求。如果使用 credentials: 'include' 选项调用 fetch(),则这些请求可能会包含 Cookie。对于 XMLHttpRequest,预期的 Cookie 通常由 truewithCredentials表示。这些 Cookie 必须进行适当标记,才能包含在跨网站请求中。

WebView 中的内容

特定平台应用中的 WebView 由浏览器提供支持。开发者需要测试影响其应用的限制或问题是否也适用于其应用的 WebView。

Android 还允许其平台专用应用直接使用 CookieManager API 设置 Cookie。与使用标头或 JavaScript 设置的 Cookie 一样,如果 Cookie 要用于跨网站使用,请考虑添加 SameSite=None; Secure

如何立即实现 SameSite

根据需要将仅在第一方环境中需要的所有 Cookie 标记为 SameSite=LaxSameSite=Strict。如果您未标记这些 Cookie,而是依赖于默认浏览器行为来处理它们,那么这些 Cookie 在不同浏览器中的行为可能会不一致,并且可能会为每个 Cookie 触发控制台警告。

Set-Cookie: first_party_var=value; SameSite=Lax

请务必将第三方环境中所需的所有 Cookie 标记为 SameSite=None; Secure。这两个属性都是必需的。如果您仅指定 None 而未指定 Secure,系统会拒绝 Cookie。为了考虑浏览器实现方面的差异,您可能需要使用处理不兼容的客户端中介绍的一些缓解策略。

Set-Cookie: third_party_var=value; SameSite=None; Secure

处理不兼容的客户端

由于这些更改(添加 None 和更新默认行为)仍相对较新,因此不同浏览器会以不同的方式处理这些更改。您可以参阅 chromium.org 上的更新页面,查看已知问题的列表,但此列表可能并不详尽。

一种可能的解决方法是,同时以新旧两种样式设置每个 Cookie:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

实现较新行为的浏览器会使用 SameSite 值设置 Cookie。未实现新行为的浏览器会忽略该值并设置 3pcookie-legacy Cookie。处理包含的 Cookie 时,您的网站应先检查是否存在新式 Cookie,然后在找不到新 Cookie 时回退到旧 Cookie。

以下示例展示了如何在 Node.js 中使用 Express 框架及其 cookie-parser 中间件执行此操作:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app
.use(cp());

app
.get('/set', (req, res) => {
 
// Set the new style cookie
  res
.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
 
// And set the same value in the legacy cookie
  res
.cookie('3pcookie-legacy', 'value', { secure: true });
  res
.end();
});

app
.get('/', (req, res) => {
  let cookieVal
= null;

 
if (req.cookies['3pcookie']) {
   
// check the new style cookie first
    cookieVal
= req.cookies['3pcookie'];
 
} else if (req.cookies['3pcookie-legacy']) {
   
// otherwise fall back to the legacy cookie
    cookieVal
= req.cookies['3pcookie-legacy'];
 
}

  res
.end();
});

app
.listen(process.env.PORT);

这种方法需要您额外设置冗余 Cookie,并在设置和读取 Cookie 时进行更改。不过,它应涵盖所有浏览器,无论其行为如何,并使第三方 Cookie 保持有效。

或者,您也可以在发送 Set-Cookie 标头时使用用户代理字符串检测客户端。请参阅不兼容的客户端列表,并为您的平台使用适当的用户代理检测库,例如 Node.js 上的 ua-parser-js 库。这种方法只需要您进行一项更改,但用户代理嗅探可能无法捕获所有受影响的用户。

在语言、库和框架中支持 SameSite=None

大多数语言和库都支持 Cookie 的 SameSite 属性。不过,由于 SameSite=None 的添加时间相对较短,因此您可能需要暂时绕过某些标准行为。这些行为记录在 GitHub 上的 SameSite 示例代码库中。

获取帮助

Cookie 在网络上的各个位置都被使用,很少有开发团队能够完全了解其网站在哪些位置设置和使用 Cookie,尤其是在跨网站用例中。当您遇到问题时,可能是所有人都首次遇到此问题,因此请随时与我们联系: