跨站请求伪造（CSRF）是一种利用用户已认证状态，在用户不知情的情况下以用户身份执行非预期操作的攻击方式。在React单页应用中，前端通常通过浏览器自动携带Cookie与后端通信，如果仅依赖Cookie做身份认证，攻击者诱导用户点击恶意页面即可完成转账、改密等敏感操作。要有效阻断这类攻击，需要让后端能够识别请求是否来源于受信任的前端界面。Cookie的SameSite属性和基于Token的验证是两种主流方案，前者由浏览器控制Cookie的发送范围，后者由应用层校验请求合法性，二者互补能覆盖更多边界场景。
Cookie SameSite属性的工作机制与局限
SameSite是Cookie的一个属性，用于规定浏览器在跨站请求时是否携带该Cookie。它有三个可选值：Strict、Lax和None。Strict最为严格，浏览器在任何跨站请求中都不发送Cookie，这能彻底防止CSRF，但会导致用户从外部链接跳转回本站时处于未登录状态，体验较差。Lax是多数浏览器的默认取值，允许在顶级导航的GET请求中携带Cookie，但会拦截跨站的POST、PUT等修改型请求，兼顾安全与体验。None则表示不限制，但必须配合Secure属性通过HTTPS传输，否则浏览器会拒绝设置。
在React应用中，SameSite通常由后端在Set-Cookie响应头中指定，前端无需额外代码。例如Node.js的Express框架可通过如下方式设置：
const express = require('express');
const app = express();
app.get('/login', (req, res) => {
res.setHeader('Set-Cookie', [
'sessionid=abc123; HttpOnly; Secure; SameSite=Lax',
'csrftoken=xyz789; Secure; SameSite=Strict'
]);
res.json({ code: 0, msg: 'logged in' });
});
app.listen(3000);
尽管SameSite能拦截绝大多数CSRF，但它并非万能。部分旧版浏览器（如IE）完全不支持该属性，会忽略设置而照常发送Cookie。此外，当系统存在多个子域且使用SameSite=None时，若任一子域存在XSS漏洞，攻击者可借该子域发起跨子域请求并携带Cookie。因此仅靠Cookie层面策略，在复杂企业环境中仍留有缺口，必须引入应用层Token验证作为第二道防线。
React中Token验证的实现流程
Token验证的核心思想是：服务器在用户登录或页面加载时下发一个随机且不可预测的CSRF Token，前端将其保存在内存或非Cookie存储中，并在后续修改型请求里通过自定义请求头（如X-CSRF-Token）携带。由于浏览器同源策略限制，恶意站点无法读取该Token，也无法自行构造带正确头的请求，从而被后端拒绝。在React项目中，常用axios拦截器统一处理Token的读取与注入。
下面示例展示如何在React使用axios，在请求发起前从页面元信息或接口获取Token并写入头信息：
import axios from 'axios';
// 假设登录后后端返回token，或页面模板中写入了meta标签
function getCsrfToken() {
const meta = document.querySelector('meta[name="csrf-token"]');
return meta ? meta.getAttribute('content') : '';
}
axios.interceptors.request.use((config) => {
const token = getCsrfToken();
if (token) {
config.headers['X-CSRF-Token'] = token;
}
return config;
});
// 发起敏感请求
axios.post('/api/transfer', { amount: 100, to: 'userB' })
.then(res => console.log(res.data))
.catch(err => console.error(err));
后端则需在校验会话Cookie的同时，比对请求头中的Token与会话中绑定的Token是否一致。若缺失或不匹配，直接返回403。这种方式的优势在于不依赖浏览器对Cookie属性的支持，即便SameSite失效，攻击者也难以伪造头。实践中注意Token不能存放在Cookie中否则失去隔离意义，且应每次会话或定期刷新以降低泄露风险。结合React组件卸载清理、路由切换重新获取等机制，可进一步提升健壮性。
两种方案在React项目中的协同配置
将SameSite与Token验证结合，并非简单叠加，而是分层防御。推荐做法是：会话Cookie设为SameSite=Lax并标记HttpOnly，防止脚本读取；CSRF Token通过独立接口或页面渲染注入，前端存于状态管理或DOM元标签，请求时放头中。这样即便浏览器不支持SameSite，Token层仍可拦截；若Token因某些原因未加载，SameSite也能挡掉大部分跨站POST。在Create React App或Next.js中，可通过中间件统一给API响应添加Set-Cookie与Token下发逻辑。
以下为一个简化的后端校验伪代码，展示双重判断逻辑：
def verify_request(request):
# 第一层：SameSite由浏览器保障，此处检查Cookie存在性
session = request.cookies.get('sessionid')
if not session:
return False, 'no session'
# 第二层：Token校验
header_token = request.headers.get('X-CSRF-Token')
server_token = session_store.get(session, {}).get('csrf_token')
if not header_token or header_token != server_token:
return False, 'csrf token mismatch'
return True, 'ok'
在调试阶段，开发者可借助浏览器开发者工具的Network面板观察请求是否带Cookie及自定义头，用Postman模拟跨站请求验证拦截效果。需避免的常见错误包括：将Token也置于Cookie导致双重携带、前端用fetch时忘记设置credentials模式、以及开发环境HTTP下使用SameSite=None却未加Secure造成设置失败。只有理清每层职责，才能在React应用中构建出既安全又对用户透明的CSRF防护体系。