SameSite 防御 CSRF 的原理
约 566 字大约 2 分钟
2025-11-02
SameSite 防御 CSRF 的原理
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 的基础上做了一些放宽：
- 同站请求：会发送 Cookie
- 跨站导航：当通过
<a href="..."链接进行 GET 请求导航时，会发送 Cookie - 其他跨站请求：通过
POST表单、<img>标签、<iframe>、AJAX 等方式发起的请求，不会发送 Cookie
防御效果：Lax 模式可以防御大部分 CSRF 攻击，特别是那些利用 POST 表单进行的攻击。同时，它允许用户从外部网站通过链接跳转到你的网站，而不会强制重新登录，改善了用户体验
现代浏览器默认行为：目前，大多数现代浏览器（如 Chrome）已经将 SameSite 的默认值设置为 Lax，即使你在服务器端没有明确设置
3. SameSite=None
这是最宽松的模式。它规定：在任何情况下都发送 Cookie，包括跨站请求
防御效果：不提供任何 CSRF 防御
使用场景：通常用于需要跨站发送 Cookie 的场景，例如：
- OAuth 认证（需要从第三方登录页面返回你的网站并携带 Cookie）
- 第三方嵌入服务，如嵌入式评论或广告
- 在这种模式下，为了安全，必须同时设置
Secure属性，即SameSite=None; Secure，要求 Cookie 只能通过 HTTPS 发送