最要紧的是用浏览器开发者工具人工验证：查响应头是否缺失x-frame-options或csp frame-ancestors；全局搜索location.hash等数据源及innerhtml等sink定位dom型xss；修改hidden字段和富文本payload实测渲染结果。
零基础学HTML漏洞扫描，最要紧的是别一上来就装工具、跑全站扫描——90%的新手卡在“不知道该看哪、为什么报这个警”，结果扫出一堆误报，反而更迷糊。真正有效的起点，是盯住浏览器开发者工具里几个固定位置，用人工验证代替盲目依赖扫描器。
怎么看响应头有没有防框架嵌入
Clickjacking风险最直观的判断依据就是响应头。打开目标页面，F12 → Network → 刷新 → 点击第一个 HTML 请求 → 查看 Response Headers：
- 必须检查
X-Frame-Options：值为DENY或SAMEORIGIN才算有效；ALLOW-FROM已被现代浏览器弃用，等同于没设 - 更推荐检查
Content-Security-Policy中是否含frame-ancestors 'none'或frame-ancestors 'self'；注意单引号不能少，且大小写敏感 - 如果这两个字段都缺失，或者值是空、
ALLOWALL（非标准写法）、*，那就基本可以确认存在框架嵌入风险
验证方法很简单：本地建一个 HTML 文件，用 <iframe src="%E7%9B%AE%E6%A0%87%E7%BD%91%E5%9D%80"></iframe> 加载，看是否能成功嵌入并显示内容。
怎么快速定位 DOM 型 XSS 的高危点
DOM 型 XSS 不发请求、不走后端，纯前端触发，所以 Burp 或 ZAP 很难抓到。直接打开开发者工具 → Sources 面板 → Ctrl+Shift+F 全局搜索这几个关键词：
-
location.search、location.hash、document.referrer—— 这些是典型的数据源（source） -
innerHTML、outerHTML、document.write、eval、setTimeout（第二个参数是字符串时）—— 这些是典型的 sink（接收器） - 找到匹配行后，右键 → “Break on > Subtree modifications” 或手动在赋值语句前加 debugger，然后改 URL 参数（比如加
#xss=test），看是否真的把未过滤内容写进了 DOM
特别注意：React/Vue 项目里 dangerouslySetInnerHTML 或 v-html 也是等效 sink，不能因为用了框架就掉以轻心。
表单隐藏字段篡改要不要管？怎么管
要管，而且优先从客户端现场验证。打开 Elements 面板，找到 <input type="hidden">，双击修改 value 值（比如把 price=99 改成 price=1），再提交表单：
- 如果服务端没校验，直接按篡改后的值下单/扣款/授权，那就是真实漏洞
- 如果返回 400、403 或提示“数据异常”，说明后端有基础防护，但还得看它用的是简单白名单（如只允许 99/199/299）还是真校验业务逻辑（比如查数据库当前价格）
- 隐藏字段里出现
user_id=123、role=admin、is_vip=true这类明显权限标识，基本可判定设计有缺陷——敏感状态不该由前端传递
这类问题几乎从不报在扫描器警报里，因为它是业务逻辑层的失控，不是语法或配置错误。
富文本编辑器输出要不要测？怎么测才不漏
要测，而且必须测渲染后的实际 DOM，不是只看接口返回的 HTML 字符串。步骤很具体：
- 在编辑器里粘贴测试 payload：
<img src="x" onerror="alert(1)">、<svg></svg>、@#@#@#@#@#@#@#@#@#@0 - 保存后，用浏览器开发者工具切换到 Elements 面板，直接搜索
alert(1)，看是否原样存在；如果被转义成<img...就安全，如果标签还活着，就危险 - 重点看事件属性（
onerror、onload）、伪协议（javascript:、data:）、SVG 标签——这些是富文本过滤器最容易放过的盲区
很多团队以为用了开源编辑器（如 TinyMCE、Quill）就万事大吉，其实默认配置往往只过滤 <script></script>，对其他攻击面毫无防御力。
真正难的从来不是工具操作，而是判断哪个响应差异有意义、哪段 JS 逻辑绕过了你预设的防护路径。所有自动化扫描结果，都得拿开发者工具过一遍真实行为——这是零基础起步唯一绕不开的手动验证环节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
