CSRF即跨站请求伪造，是一种利用用户已登录的合法身份，在用户不知情的情况下发起恶意请求的攻击方式。攻击者通常会构造恶意页面，诱导用户访问后自动触发对目标站点的请求，由于浏览器会自动携带用户的登录凭证，目标站点会误认为是用户主动发起的合法请求，从而执行攻击者预设的操作。
CSRF攻击的常见场景
常见的CSRF攻击场景包括修改用户账户信息、发起转账操作、删除重要数据等。比如攻击者构造一个隐藏的表单，当用户访问恶意页面时，表单会自动提交到目标银行的转账接口，携带用户的登录Cookie，完成恶意转账操作。这类攻击之所以能成功，主要是因为Web的身份验证机制依赖Cookie，且浏览器会自动在请求中携带对应域名的Cookie。
JavaScript层面的CSRF防御手段
1. 利用同源策略限制跨域请求
同源策略是浏览器最核心的安全机制之一，它限制了一个源加载的文档或脚本如何与另一个源的资源进行交互。同源要求协议、域名、端口三者完全一致。如果请求不满足同源要求，浏览器会直接拦截响应，避免恶意站点获取敏感数据。
我们可以通过以下代码检查请求是否符合同源要求：
// 检查目标URL是否与当前页面同源
function isSameOrigin(targetUrl) {
const currentOrigin = window.location.origin;
const targetOrigin = new URL(targetUrl).origin;
return currentOrigin === targetOrigin;
}
// 示例：检查转账接口是否同源
const transferUrl = 'https://ippipp.com/api/transfer';
if (isSameOrigin(transferUrl)) {
console.log('请求符合同源策略，可正常发起');
} else {
console.log('请求跨域，需额外处理');
}
2. 合理配置CORS跨域资源共享
如果业务需要跨域请求，需要正确配置CORS规则，避免将Access-Control-Allow-Origin设置为通配符*，否则会允许任意第三方站点发起跨域请求，增加CSRF攻击风险。正确的做法是只允许信任的域名跨域访问。
以下是Node.js服务端配置CORS的示例：
const express = require('express');
const app = express();
// 允许跨域的白名单
const allowedOrigins = ['https://ipipp.com', 'https://trusted-site.com'];
app.use((req, res, next) => {
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type,CSRF-Token');
// 不允许携带凭证的通配符配置，避免安全风险
res.setHeader('Access-Control-Allow-Credentials', 'true');
}
next();
});
app.listen(3000);
3. 使用CSRF Token验证请求合法性
CSRF Token是目前最有效的防御手段之一，核心思路是服务端生成一个随机的、不可预测的Token，嵌入到前端页面的表单或请求头中，每次发起敏感请求时携带该Token，服务端验证Token的有效性，如果Token不存在或不匹配，则拒绝请求。
前端获取并携带CSRF Token的示例：
// 从页面meta标签中获取CSRF Token
function getCSRFToken() {
const metaTag = document.querySelector('meta[name="csrf-token"]');
return metaTag ? metaTag.content : '';
}
// 发起转账请求时携带CSRF Token
async function sendTransferRequest(amount, targetAccount) {
const csrfToken = getCSRFToken();
try {
const response = await fetch('https://ipipp.com/api/transfer', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'CSRF-Token': csrfToken
},
body: JSON.stringify({
amount: amount,
target: targetAccount
}),
credentials: 'include' // 携带Cookie
});
const result = await response.json();
console.log('转账结果:', result);
} catch (error) {
console.error('请求失败:', error);
}
}
4. 避免使用GET请求处理敏感操作
GET请求的参数会暴露在URL中，且容易被恶意站点通过<img>、<script>等标签自动发起，因此敏感操作如转账、修改密码等必须使用POST、PUT等请求方法，降低被CSRF攻击的概率。
其他辅助防御措施
- 设置Cookie的
SameSite属性为Strict或Lax，限制Cookie在跨站请求中不被携带，从根源上避免CSRF利用Cookie的问题 - 敏感操作增加二次验证，比如短信验证码、人脸验证等，即使请求被伪造，攻击者也无法完成验证
- 定期检查前端代码，避免存在可被利用的XSS漏洞，因为XSS可以窃取CSRF Token，绕过Token验证机制
总结
CSRF防御需要前后端配合完成，JavaScript在前端层面可以通过同源检查、正确携带验证信息、规范请求方法等方式提升防御能力。开发者需要充分理解CSRF的攻击原理，结合业务场景选择合适的防御方案，同时做好相关安全配置的检查，才能有效降低CSRF攻击带来的风险，保障用户和业务的财产安全。
CSRF防御JavaScript安全编程同源策略CORSCSRF_token修改时间：2026-06-16 22:00:31