CSRF防护需前后端协同，前端可通过SameSite Cookie、自定义请求头、同步Token及双重Cookie提交等措施辅助防御，核心在于配合后端实现安全策略。
CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的前端安全漏洞，攻击者诱导用户在已登录的状态下执行非本意的操作。虽然主要防护应在后端实现，但前端可以通过一些手段配合提升安全性。以下是基于 JavaScript 的常见 CSRF 防护实践与实现方式。
理解CSRF攻击原理
CSRF 利用用户在目标网站的认证状态，通过第三方站点发起伪造请求。例如：用户登录了银行系统，未退出的情况下访问恶意网站，该网站自动提交一个转账请求到银行系统，而浏览器会自动携带用户的 Cookie，导致请求被合法执行。
关键点在于：攻击者无法获取用户的 Cookie，但可以利用浏览器自动携带 Cookie 的机制发起请求。
前端可参与的防护措施
虽然 CSRF 防护的核心逻辑通常由后端完成，前端仍可通过以下方式协助防御：
立即学习“Java免费学习笔记（深入）”；
1. 使用 SameSite Cookie 属性（推荐）设置 Cookie 的 SameSite 属性为 Strict 或 Lax，可有效阻止跨站请求携带 Cookie。
示例（由服务端设置）：
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
前端虽不能直接设置此属性，但应确保与后端协作启用该策略。
2. 添加自定义请求头（如 X-Requested-With）前端在发送敏感请求时，添加自定义请求头（如 X-Requested-With: XMLHttpRequest），后端校验该头是否存在。
使用 fetch 示例：
fetch('/api/transfer', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Requested-With': 'XMLHttpRequest'
},
body: JSON.stringify({ to: 'user2', amount: 100 })
})
后端需检查该头，若缺失则拒绝请求。注意：此方法依赖同源策略，防止第三方脚本伪造该头。
3. 同步 Token 模式（Synchronizer Token Pattern）后端生成一次性 Token，嵌入页面（如隐藏字段或 meta 标签），前端在请求中携带该 Token，后端验证其有效性。
实现步骤：
- 后端渲染页面时注入 Token：
<meta name="csrf-token" content="abc123xyz">
- JavaScript 读取并附加到请求头：
const token = document.querySelector('meta[name="csrf-token"]').getAttribute('content');
fetch('/api/delete', {
method: 'DELETE',
headers: {
'X-CSRF-Token': token,
'Content-Type': 'application/json'
}
})
后端对比 Token 是否匹配，防止重放和伪造。
4. 双重 Cookie 提交（Double Submit Cookie）前端在请求中额外添加一个与 Cookie 中相同的 Token 字段，后端比对两者是否一致。
流程：
- 后端在 Set-Cookie 时写入 csrf-token=abc123
- 前端读取该 Cookie（需非 HttpOnly），并在请求体或头中再次发送
示例（使用 axios）：
// 假设从 Cookie 获取 token
const csrfToken = getCookie('csrf-token');
axios.post('/api/action', {
data: 'example',
csrfToken // 请求体中包含
});
后端验证请求中的 token 与 Cookie 中的一致性。此方法无需服务器存储 Token，适合分布式系统。
避免常见误区
前端不应单独依赖 Referer 或 Origin 头进行判断，这些信息可能被篡改或缺失。真正的验证必须由后端完成。
不要将敏感操作绑定在 GET 请求上，避免链接被恶意调用。
静态资源托管站点更需警惕，即使无登录态，若用户处于同一浏览器环境，仍可能受攻击影响。
基本上就这些。前端能做的有限，关键是与后端协同，确保 Token 机制或 SameSite 策略落地。安全是全链路的事，JavaScript 不是主角，但也不能缺席。
