html本身不直接存在csrf漏洞，但缺失、无samesite cookie、滥用get执行敏感操作或token可预测等设计，均构成高危风险。
HTML 代码里本身不直接存在跨站请求伪造（CSRF）漏洞——漏洞出在服务端逻辑和前端交互设计上，但 HTML 是攻击载荷的“落地界面”，排查必须从它开始。
检查表单是否缺失 csrf_token 隐藏字段
CSRF 防御最常见方式是服务端下发一次性 token，并要求每次敏感操作都携带。如果 HTML 表单中没有 <input type="hidden" name="csrf_token" value="...">，且后端又没做其他校验（如 SameSite Cookie、Referer 检查），基本可判定存在风险。
- 重点扫描所有
<form method="POST"></form>或触发 POST 请求的按钮（如fetch()、XMLHttpRequest）对应的服务端接口 - 注意：Vue/React 等框架渲染的表单可能动态注入 token，需查看运行时 DOM，而非原始 HTML 源码
- 若 token 值固定、空、或可被预测（如时间戳+简单哈希），仍算无效防护
识别无保护的 GET 请求执行敏感操作
GET 请求本不该修改状态，但不少老系统用 @#@#@#@#@#@#@#@#@#@0 或 <img src="/logout"> 实现功能，这类写法极易被 CSRF 利用。
- 搜索 HTML 中所有
href属性含/delete、/logout、/transfer、/change_password等关键词的<a></a>或<img>标签 - 确认对应后端路由是否真为只读；若返回 200 且有副作用（如删库、登出），就是高危点
- 浏览器会自动发起
<img>、<link>、<iframe></iframe>的 GET 请求，无需用户点击
验证 Cookie 是否设置了 SameSite 属性
现代浏览器默认对 Cookie 加强限制，但前提是服务端明确声明 SameSite=Lax 或 SameSite=Strict。仅靠前端 HTML 无法设置，但可通过响应头或开发者工具快速验证。
- 打开浏览器 DevTools → Network → 任意一个带身份认证的请求 → 查看
Response Headers中是否有Set-Cookie: ...; SameSite=Lax - 若缺失
SameSite，或值为None却未配Secure（即 HTTPS 下才发送），则 CSRF 风险显著升高 - 注意：
SameSite是服务端响应头控制，HTML 里写<meta http-equiv="set-cookie">无效
真正难排查的不是 HTML 本身，而是那些看似“安全”的交互：比如用 fetch() 发送 JSON，但没带 token；或者 token 存在 localStorage 里被 JS 读取后手动塞进 header——这种模式一旦页面存在 XSS，token 就会被盗取，CSRF 防护形同虚设。所以 HTML 排查只是起点，必须联动看 JS 如何发请求、后端如何校验、Cookie 如何下发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
