1. SameSite=Strict

这是最严格的模式。它规定：只有当请求是同站发出的，浏览器才会发送 Cookie

同站请求：比如你在 bank.com 内部点击一个链接，请求 bank.com/profile，浏览器会发送 Cookie
跨站请求：当你在 evil.com 上，通过任何方式（表单提交、<img> 标签、<a> 链接）向 bank.com 发起请求时，浏览器都不会发送 Cookie

防御效果：Strict 模式可以完全防御 CSRF 攻击，因为恶意请求无法携带会话 Cookie

缺点：过于严格，可能会影响用户体验。例如，如果你从其他网站（如社交媒体或搜索引擎）点击一个链接跳转到 bank.com，因为这是跨站导航，Strict 模式下的 Cookie 也不会被发送，你可能需要重新登录

2. SameSite=Lax

这是折中且更常用的模式。它在 Strict 的基础上做了一些放宽：

防御效果：Lax 模式可以防御大部分 CSRF 攻击，特别是那些利用 POST 表单进行的攻击。同时，它允许用户从外部网站通过链接跳转到你的网站，而不会强制重新登录，改善了用户体验

现代浏览器默认行为：目前，大多数现代浏览器（如 Chrome）已经将 SameSite 的默认值设置为 Lax，即使你在服务器端没有明确设置

3. SameSite=None

这是最宽松的模式。它规定：在任何情况下都发送 Cookie，包括跨站请求

防御效果：不提供任何 CSRF 防御

使用场景：通常用于需要跨站发送 Cookie 的场景，例如：

OAuth 认证（需要从第三方登录页面返回你的网站并携带 Cookie）
第三方嵌入服务，如嵌入式评论或广告
在这种模式下，为了安全，必须同时设置 Secure 属性，即 SameSite=None; Secure，要求 Cookie 只能通过 HTTPS 发送

3.1 SameSite 防御 CSRF 的原理

results matching ""