CSRF是跨站请求伪造，攻击者利用用户已登录状态和自动携带的Cookie，诱使其浏览器向受信任网站发送恶意请求；其核心在于服务端仅凭Cookie放行请求，而前端无法单独防御，必须依赖后端校验CSRF Token等机制协同防护。
CSRF 攻击不是前端能单独拦住的，它本质是服务端信任了“带有效 Cookie 的请求”，而前端只负责把 Token 传过去——没传、传错、没校验，后端一松懈，就漏了。
CSRF 是什么：不是 XSS，也不需要执行脚本
用户已登录银行网站，Cookie 自动带上；此时他点开攻击者发来的恶意页面（比如一张图、一封邮件），该页面悄悄向银行发起一个转账请求：POST /transfer，参数全写死。浏览器照发，因为 Cookie 合法，银行服务器就认了——整个过程用户毫无感知。
关键点在于：
- 攻击依赖用户当前会话（即 Cookie 未过期且未登出）
- 目标接口必须是“仅靠 Cookie 就放行”的状态操作（如修改邮箱、删账号、付款）
- 请求参数可被完全预测（不能含服务端动态生成的随机字段）
Html.AntiForgeryToken() 在 ASP.NET MVC 中怎么用
这是最省心的集成方案，但必须前后端配对生效。
立即学习“前端免费学习笔记（深入）”；
前端要写两处：
- 在
@using (Html.BeginForm(...))表单内加@Html.AntiForgeryToken()，它会渲染成一个隐藏字段，值类似<input name="__RequestVerificationToken" value="..."> - Ajax 请求需手动取值：用
$('input[name=__RequestVerificationToken]').val()拿到 token，再塞进headers: { 'RequestVerificationToken': token }
后端必须同步加特性：
- 对应 Action 加
[ValidateAntiForgeryToken]，否则 token 不校验 - 若用 Web API 或前后端分离，
[ValidateAntiForgeryToken]默认不生效（它只认 form post + cookie），得自己写过滤器或改用[AutoValidateAntiforgeryToken]
SameSite Cookie 属性为什么不能替代 CSRF Token
SameSite=Lax 能挡住大部分 GET 型 CSRF（比如图片链接触发的转账），但对 POST 表单提交、带 fetch() 的 JSON 请求、甚至某些浏览器的表单自动提交行为，仍可能失效。
更实际的问题是兼容性：
- 老版本 Safari 和部分安卓 WebView 忽略
SameSite设置 -
SameSite=None必须搭配Secure（HTTPS），HTTP 站点直接不发 Cookie - 它防不住“同站内子域名互相调用”这类场景（比如
admin.example.com被blog.example.com利用）
所以 SameSite 是加固项，不是替代项；Token 才是兜底防线。
前端容易漏掉的三个 Token 细节
Token 不是加了就万事大吉，这几个点一错，等于没加：
- 页面缓存导致旧 Token 被复用：用
<meta http-equiv="Cache-Control" content="no-cache">或服务端设Cache-Control: no-store - 多标签页共用一个 Session，换标签刷新页面后，旧 tab 提交时 token 已失效——得监听
pageshow事件重拉新 token - SPA 应用里，
fetch或axios默认不发 Cookie，必须显式加credentials: 'include'，否则后端收不到 session，自然也比对不了 token
真正卡住攻击链的，从来不是某个炫技的机制，而是 Token 生成、传输、校验三环节严丝合缝——少一环，前面全白做。
