每个 Cookie 都包含一个键值对,以及一些用于控制该 Cookie 的使用时间和地点的属性。
通过引入 SameSite
属性(在 RFC6265bis 中定义),您可以声明您的 Cookie 是否仅限于第一方环境或同一网站环境。准确理解此处“网站”的含义会很有帮助。
网站是域名后缀和域名前面一部分的组合。例如,www.web.dev
网域属于 web.dev
网站。
关键词:如果用户位于 www.web.dev
上,并且向 static.web.dev
请求图片,则为同网站请求。
公共后缀列表定义了哪些网页会被视为位于同一网站上。它不仅依赖于顶级域名(如 .com
),还可以包含 github.io
等服务。这样,your-project.github.io
和 my-project.github.io
就可以算作不同的网站。
关键词:如果用户位于 your-project.github.io
上,并且向 my-project.github.io
请求图片,则为跨网站请求。
使用 SameSite
属性声明 Cookie 用法
Cookie 上的 SameSite
属性提供了三种不同的方式来控制此行为。您可以选择不指定该属性,也可以使用 Strict
或 Lax
将 Cookie 限制为仅供同网站请求使用。
如果您将 SameSite
设置为 Strict
,则 Cookie 只能在第一方环境中发送;也就是说,当获取该 Cookie 的网站与浏览器地址栏中显示的网站匹配时,才会发送 Cookie。因此,如果 promo_shown
Cookie 设置如下:
Set-Cookie: promo_shown=1; SameSite=Strict
当用户访问您的网站时,Cookie 会按预期随请求一起发送。
但是,如果用户通过另一个网站的链接进入您的网站,则系统不会针对该初始请求发送 Cookie。
这对于与始终位于初始导航之后的功能(例如更改密码或购买)相关的 Cookie 非常有用,但对于 promo_shown
这样的 Cookie 而言限制性太强。如果您的读者通过该链接进入网站,他们希望发送 Cookie,以便应用他们的偏好设置。
SameSite=Lax
允许浏览器发送带有这些顶级导航的 Cookie。例如,如果其他网站引用了您网站的内容,在这种情况下,会使用您的猫咪照片并提供指向您文章的链接,如下所示:
<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
将 Cookie 设置为 Lax
,如下所示:
Set-Cookie: promo_shown=1; SameSite=Lax
当浏览器为对方的博客请求 amazing-cat.png
时,您的网站不会发送 Cookie。但是,当读者点击您网站上的 cat.html
链接时,该请求确实会包含该 Cookie。
建议您以这种方式使用 SameSite
,将影响网站显示的 Cookie 设置为 Lax
,将与用户操作相关的 Cookie 设置为 Strict
。
您还可以将 SameSite
设置为 None
,以表明您希望在所有上下文中发送 Cookie。如果您提供了可供其他网站使用的服务(例如 widget、嵌入式内容、联属营销计划、广告或在多个网站上进行的登录),请使用 None
来确保您的意图清晰明确。
![三个 Cookie 被标记为“无”“宽松”或“严格”(具体取决于其情境)](https://web.developers.google.cn/static/articles/samesite-cookies-explained/image/three-cookies-labelled-no-495f9afccf1cd.png?authuser=5&hl=sv)
None
、Lax
或 Strict
。
不采用 SameSite 的默认行为的更改
浏览器支持
- 80
- 86
- x
SameSite
属性受到广泛支持,但尚未得到广泛采用。过去,如果在未设置 SameSite
的情况下设置 Cookie,系统会默认在所有环境中发送 Cookie,这会导致用户容易受到 CSRF 攻击和信息意外泄露。为了鼓励开发者表明自己的意图并为用户提供更安全的体验,IETF 的 Progressively Better Cookies 提案提出了两项主要变更:
- 没有
SameSite
属性的 Cookie 被视为SameSite=Lax
。 - 具有
SameSite=None
的 Cookie 还必须指定Secure
,这意味着它们需要一个安全上下文。
这两项变更均向后兼容已正确实现旧版 SameSite
属性的浏览器,以及不支持早期 SameSite
版本的浏览器。旨在通过明确指定 Cookie 行为和预期用途,降低开发者对浏览器默认行为的依赖。任何无法识别 SameSite=None
的客户端都应忽略它。
默认为 SameSite=Lax
如果您在发送 Cookie 时未指定其 SameSite
属性,浏览器会将该 Cookie 视为已设置为 SameSite=Lax
。不过,我们仍建议您明确设置 SameSite=Lax
,以确保您在各种浏览器中的用户体验更加一致。
“SameSite=None
”必须是安全的
当您使用 SameSite=None
创建跨网站 Cookie 时,还必须将它们设置为 Secure
,以便浏览器接受它们:
Set-Cookie: widget_session=abc123; SameSite=None; Secure
从 Chrome 76 开始,您可以通过启用 about://flags/#cookies-without-same-site-must-be-secure
对此行为进行测试;从 Firefox 69 开始,您可以通过在 about:config
中设置 network.cookie.sameSite.noneRequiresSecure
来测试此行为。
我们还建议您尽快将现有 Cookie 更新为 Secure
。
如果您依赖在网站上提供第三方内容的服务,请确保您的服务提供商更新其 Cookie,并更新您网站的所有代码段或依赖项,以确保其使用新行为。
SameSite
饼干食谱
如需详细了解如何更新 Cookie 以成功处理这些 SameSite=None
更改以及浏览器行为差异,请参阅后续文章 SameSite Cookie 配方。
感谢 Lily Chen、Malte Ubl、Mike West、Rob Dodson、Tom Steiner 和 Vivek Sekhar 的贡献和反馈。
Pille-Riin Priske 发布的 Cookie 主打图片(由 Unsplash 用户)