React 与 API 配置中的 CSRF 防护

跨站请求伪造（CSRF）是一种攻击：恶意网站诱骗用户的浏览器向您的接口发送经过身份验证的请求。由于浏览器会自动为请求附加 Cookie，服务器无法区分来自您应用的合法请求和来自攻击者网站的伪造请求。

Cookie 是 CSRF 漏洞的根本原因。当用户登录您的应用后，其会话 Cookie 会存储在浏览器中。当用户访问攻击者的页面时，攻击者可以触发表单提交或向您的接口发送请求，而浏览器会自动附加会话 Cookie，从而使恶意请求通过身份验证。

SameSite Cookie 属性用于告诉浏览器在跨站请求中何时包含 Cookie。它有三个值：Lax（现代浏览器中的默认值——阻止跨站 POST，但允许 GET）、Strict（阻止所有跨站请求，包括 GET 导航）以及 None（允许跨站请求，但要求启用 HTTPS Secure 标志）。

SameSite=Lax 会阻止跨站的 POST、PUT、DELETE 和 PATCH 请求——这些都是用于执行修改操作的方法。如果您的接口只使用 GET 进行读取，并使用 POST 执行所有修改操作，那么在现代浏览器中，SameSite=Lax 就能有效防止 SPA 受到 CSRF 攻击。这是目前大多数应用所依赖的基础防护措施。

双重提交 Cookie 模式是一种 CSRF 缓解措施：服务器将随机 CSRF 令牌设置在非 HttpOnly Cookie 中。客户端读取该 Cookie 的值，并将其作为自定义请求标头包含在请求中，例如 X-CSRF-Token。服务器会验证标头值是否与 Cookie 值匹配。攻击者无法从其他源读取该 Cookie，因此无法设置正确的标头。

同步令牌模式会在服务器上为每个用户会话生成唯一的 CSRF 令牌。对于 HTML 表单，令牌会嵌入隐藏字段中。对于 SPA 接口调用，令牌通过端点或元标签提供，并在自定义标头中发送。服务器会在每个改变状态的请求中验证该令牌。

将 JWT 存储在内存或 localStorage 中，并通过 Authorization: Bearer 标头发送 JWT 的 React SPA，不易受到经典 CSRF 攻击。CSRF 攻击利用的是基于 Cookie 的身份验证；由于 CORS 限制，攻击者的页面无法在跨源请求中设置自定义标头，因此无法伪造 Authorization 标头。

简单的跨源请求（表单 POST、图片加载）不允许使用自定义标头。只有经过 CORS 预检的请求才能包含自定义标头，而预检请求必须获得服务器的明确许可。要求所有修改操作都带有自定义标头（例如 X-Requested-With: XMLHttpRequest）的接口，可以天然防范简单的 CSRF 攻击。

CORS 控制哪些来源可以读取跨来源请求的响应。CSRF 关注哪些来源可以发起会改变状态的请求。将 CORS 配置为限制来源并不能防止 CSRF——浏览器仍会发送请求和 Cookie，CORS 只控制 JavaScript 是否能看到响应。CSRF 攻击不需要读取响应。

请按以下方式配置会话 Cookie：HttpOnly: true（防止 JavaScript 读取 Cookie，从而阻止基于 XSS 的令牌窃取）、Secure: true（仅通过 HTTPS 发送）、SameSite: Lax 或 Strict（防止 CSRF），以及合适的 Max-Age 或过期时间。这四个属性结合使用，可以显著强化会话管理。

Next.js 应用路由使用服务器操作，而服务器操作属于 POST 请求。Next.js 通过检查 Origin 标头是否与主机匹配来实现 CSRF 防护——来自意外来源的请求会被拒绝。这项内置检查与 SameSite=Lax 会话 Cookie 结合使用，可以为基于服务器操作的状态变更提供可靠的 CSRF 防护。

哪一种 SameSite Cookie 值可以阻止跨站 POST 请求，但允许跨站 GET 导航？

CSRF 利用基于 Cookie 的身份验证，诱使浏览器发送经过身份验证的跨站请求。SameSite=Lax 是现代浏览器的基础防御措施。双重提交 Cookie 和同步器令牌模式可以提供额外保护。在授权标头中使用 JWT 的 React SPA 天生能够抵御 CSRF。自定义必需标头和 CORS 预检也可以缓解 CSRF。会话 Cookie 始终应结合使用 HttpOnly + Secure + SameSite。