存在csrf风险需满足：表单无服务端生成且绑定会话的csrf_token字段；action/method可被外部构造；服务端未校验token或referer；隐藏字段含未校验的关键参数。
直接看表单里有没有 csrf_token 字段
没有 csrf_token，基本可以判定存在CSRF风险。重点检查所有执行敏感操作的表单，比如修改密码、转账、删除账户、绑定邮箱等。注意：仅靠前端JS生成的token（如用 Math.random() 或时间戳拼接）不可信，必须由服务端生成并绑定用户会话。
检查 form 的 action 和 method 是否可被外部构造
如果一个表单是 POST 但没带 token，攻击者就能用 HTML 构造完全相同的 form 并自动提交；如果是 GET，更简单——只要把参数拼进 URL，用 <img src="..."> 或诱导点击就能触发。常见陷阱：method="POST" 不等于安全，很多开发者误以为“改 POST 就防 CSRF”。
验证服务端是否真的校验了 token 或其他防护头
光有 csrf_token 字段不等于防护有效。需要抓包重放请求，做两件事：
– 去掉 csrf_token 字段或改错值，看是否还能成功提交；
– 去掉 Referer 或伪造为其他域名，观察响应是否拒绝。
若两者都可通过，说明服务端未校验，漏洞成立。特别注意：仅校验 Referer 存在性（而非具体域名）或允许空 Referer，都属于无效防护。
留意隐藏字段是否承载关键业务逻辑参数
比如表单里有 <input type="hidden" name="user_id" value="123">，且后端直接信任该值来决定操作对象，这就可能和 CSRF 组合出越权问题。即使有 token，只要业务参数可被篡改，攻击者就能伪造请求去操作其他用户的数据。这类字段往往藏在开发者工具的 Elements 面板里，容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
