JavaScript本身不发起CSRF攻击，而是作为载体诱使浏览器发送带Cookie的恶意请求；防护必须由服务端实现，如CSRF Token、SameSite Cookie或双重Token机制。
JavaScript CSRF（跨站请求伪造）攻击不是通过 JavaScript 直接发起的“CSRF 攻击”，而是指攻击者利用用户已登录的合法身份，在用户不知情时，诱使其浏览器向目标网站发送恶意请求——这些请求由浏览器自动携带 Cookie（含 session 信息），而前端 JavaScript 本身通常无法读取或伪造其他域的 Cookie。真正的问题在于：前端 JS 发起的跨域请求（如 fetch 或 XMLHttpRequest）若未受控，可能被诱导执行非预期操作（例如提交表单、调用 API），尤其当后端缺乏有效防护时。
CSRF 的本质是服务端信任了“来自用户浏览器的请求”，却未验证该请求是否由用户真实意愿触发
JavaScript 本身不“发起 CSRF”，但它常作为载体（比如嵌入恶意页面的脚本）触发浏览器发出带凭证的请求。关键点：
- 浏览器对同源请求自动携带 Cookie，JS 无需显式传 token；
- 跨域请求（如 POST 到 bank.com）若目标服务允许凭 Cookie 认证且无额外校验，就可能被滥用；
- 现代浏览器的 CORS 策略会阻止 JS 读取跨域响应，但不会阻止跨域请求发出（尤其是简单请求如 GET/POST + 普通 Content-Type）。
不能依赖 JavaScript 验证来源（Referer / Origin）
前端 JS 无法可靠获取或校验请求的真实来源：
-
document.referrer可被禁用或伪造（如从本地文件打开、隐私模式、中间代理）； - JS 无法读取跨域响应头（如
Origin），也无法拦截自身发出的请求去检查 header； - 试图在 JS 中判断
window.location.origin并拼接请求？这只能约束“你写的代码”，无法防御别人仿写一个表单或 curl 请求。
真正的防护必须在服务端实现
验证请求来源和意图，是后端的责任。常用且有效的方案：
立即学习“Java免费学习笔记（深入）”；
-
CSRF Token（推荐）：服务端为每个用户会话生成一次性或短期有效的随机 token，要求所有状态变更请求（POST/PUT/DELETE）必须携带该 token（通常放在 form hidden 字段或请求 header 如
X-CSRF-Token）。服务端比对 session 中存储的 token 是否匹配且未使用过。 -
SameSite Cookie 属性：设置关键 Cookie（如 sessionid）的
SameSite=Strict或SameSite=Lax，可阻止浏览器在跨站请求中自动携带该 Cookie，大幅降低 CSRF 风险（注意兼容性，老版本浏览器不支持）。 -
双重 Cookie/Token 模式（适合纯 API 场景）：前端 JS 从 cookie 读取一个 token（
csrf_token），再将其作为 header（如X-XSRF-Token）发送；服务端比对 header 中的值与 cookie 中的值是否一致（Angular 的默认机制）。注意：仅适用于 cookie 可被 JS 读取的场景，且需配合HttpOnly=false—— 这会略微增加 XSS 风险，需确保 XSS 防护到位。 -
校验 Origin / Referer 请求头（辅助手段）：服务端检查 HTTP 请求头中的
Origin（优先）或Referer，确认其属于白名单域名。这不是替代方案，因为Origin在某些请求中可能缺失（如 POST 表单跳转），且无法防御同域 XSS 引发的伪造。
前端能做的配合事项
虽然验证主体在后端，前端仍需规范协作：
- 敏感操作（如转账、改密码）前，主动向后端请求一次 fresh CSRF token，并在后续请求中正确携带；
- 使用
fetch时显式设置credentials: 'include'（默认是same-origin），确保 Cookie 正常发送； - 避免在 URL 中暴露敏感参数（GET 请求易被日志、代理、Referer 泄露）；
- 不使用
eval、不渲染不可信 HTML/JS，严防 XSS —— 因为 XSS 可直接读取 token 或伪造请求，使 CSRF 防护失效。
