### 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 发送