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