CSRF攻击本质是利用用户已登录会话，通过恶意JS静默发起带Cookie的请求；防护核心是后端签发一次性Anti-CSRF Token并校验，辅以SameSite Cookie、Referer检查等手段，严禁GET改状态或前端生成token。
JavaScript环境下的CSRF攻击，本质是利用用户已登录的会话状态，通过恶意页面里的JS代码自动发起目标网站的请求（比如转账、改密），而浏览器会悄悄带上Cookie，让服务器误以为是用户本人操作。
CSRF在JS里怎么被利用
常见手法不是靠用户点按钮，而是脚本静默执行：
- 用
document.createElement('form')构造隐藏表单，填好参数后form.submit() - 用
fetch或XMLHttpRequest发POST请求，credentials: 'include'确保带Cookie - 甚至用
最靠谱的防护：Anti-CSRF Token机制
核心思路是“服务端发令牌，前端必须回传，且每次不重复”：
- 用户访问表单页或进入SPA主页面时，后端返回一个一次性token（如
csrf_token=abc123），写入HTML hidden input 或注入到JS变量中 - 所有敏感请求（AJAX或表单提交）必须在请求头（如
X-CSRF-Token）或请求体中带上该token - 后端收到请求后，比对token是否有效且未使用过；不匹配或已失效则直接拒绝
- 注意：token不能只存在JS变量里——XSS漏洞下可能被窃取；建议配合HttpOnly Cookie存储服务端校验用的签名值
辅助但不可单独依赖的手段
这些能提高门槛，但都有绕过可能，适合叠加使用：
立即学习“Java免费学习笔记（深入）”；
-
SameSite Cookie属性：把关键Cookie设为
SameSite=Lax或Strict，可阻止大部分跨站带Cookie的GET/POST请求 -
Referer检查：后端验证请求头中的
Referer是否来自自家域名；但部分浏览器或隐私模式可能不发Referer - 双重提交Cookie：前端读取一个含token的Cookie，再把它作为请求头或参数提交；服务端比对两者一致即可——无需服务端存token状态，适合无状态API
开发中容易忽略的关键点
防护失效常因细节疏漏：
- API只接受JSON？别忘了
Content-Type: application/json本身不能防CSRF——恶意站点仍可用fetch发带Cookie的JSON请求 - SPA应用中，token需随页面加载时获取，并在后续每个请求中显式携带；不能只靠全局axios拦截器“默认加”，要确保首次token加载成功
- 不要用GET请求做状态变更操作（如
/delete?id=123），这类接口极易被标签触发 - 前端生成token？不行。必须由后端安全生成并绑定用户会话，否则毫无意义
基本上就这些。Token机制是基石，SameSite和Referer是加分项，而杜绝GET改状态、避免前端生成token，是不踩坑的前提。
