不防 csrf，它只是 token 的搬运工；真正起作用的是服务端动态生成、绑定 session 并严格校验，前端硬编码、缓存或 js 动态填充均破坏防护。
<input type="hidden"> 不防 CSRF，它只是 Token 的搬运工——服务端没做对，前端塞再多 hidden 字段也没用。
为什么 <input type="hidden"> 本身不提供任何安全防护
用户打开 DevTools，两秒就能改掉 value；它和 <input name="user_id"> 一样裸露在 DOM 里，没有签名、不加密、不校验来源。真正起作用的是服务端：每次渲染页面时动态生成 Token、绑定当前 session、提交时严格比对。如果服务端用静态字符串硬编码 value="abc123"，那这个 hidden 字段就等于公开广播攻击入口。
- 常见错误现象：
Invalid CSRF token错误，往往不是前端写错了，而是服务端 session 中的 Token 已更新，但页面 DOM 还卡在旧值（比如 CDN 缓存了 HTML） - 多标签页同时操作时，某些 PHP 实现用一次性 Token，第二个表单提交必然失败
- 浏览器 F12 → Elements 面板里直接右键修改
value→ 提交 → 服务端若没校验，攻击即成功
Django/Flask 中 <input type="hidden"> 的正确生成方式
框架必须在每次 HTTP 响应中实时注入 Token，不能缓存、不能复用、不能 JS 动态填 —— 否则就断链。Django 的 {% csrf_token %} 和 Flask 的 {{ csrf_token() }} 都是服务端模板函数，它们输出的 <input type="hidden" name="csrfmiddlewaretoken" value="..."> 才有效。
- 禁止把整个 HTML 页面丢给 CDN 缓存，否则所有用户看到同一个
value，Token 失效或被复用 - 禁止在 JS 里用
document.querySelector('input[name="csrfmiddlewaretoken"]').value = localStorage.getItem('token')—— XSS 下立刻被盗 - name 属性必须和服务端约定一致：Django 默认是
csrfmiddlewaretoken，Flask 默认是csrf_token，拼错一个字母，后端收不到字段
哪些场景绝对不能用 <input type="hidden"> 传 Token
它只适用于传统 form submit 场景。一旦脱离这个上下文，强行塞进去反而破坏防护逻辑。
- AJAX 请求（如
fetch('/api/like', {method: 'POST'})）→ 必须从<meta name="csrf-token" content="...">读取，再设headers: {'X-CSRF-Token': token}；否则服务端收不到，直接403 - 页面含多个 form（评论+点赞+收藏）→ 每个 form 必须单独渲染自己的 Token；共用一个 hidden 字段，提交时可能覆盖或误读
- SPA 应用（React/Vue）→ 首屏 HTML 只给一次 Token，后续 API 调用应依赖 Cookie（
SameSite=Lax）或从服务端接口单独获取 - Token 存在 URL 参数或 localStorage 里再填进 hidden 字段 → 违反“禁止从客户端存储读 Token”原则，XSS 下极易泄露
name 和 value 哪个更容易出问题？
name 错了，后端根本收不到字段；value 错了，后端收到脏数据。两者都致命，但 name 更常被忽略。
- 拼写不一致：前端写
name="csrf"，后端却按$_POST["csrf_token"]取值 → 返回undefined - 未动态赋值：模板里写死
value="hardcoded"，但实际需要服务端每次生成 → 提交时 Token 永远过期 - 多个同名字段：页面不小心写了两个
name="csrfmiddlewaretoken"→ 浏览器只提交最后一个，后端校验失败 - JS 动态写入时 DOM 没就绪：
document.getElementById("token")找不到元素 → 加DOMContentLoaded或把 script 放 body 底部
真实项目里最容易被忽略的，是以为只要页面上有这个元素，后端就一定能拿到值 —— 其实只要 name 缺失、拼错、或 JS 更新逻辑被绕过，整个 CSRF 防护链就断了。
