HTML漏洞排查需聚焦数据流向，重点检查innerHTML、outerHTML、document.write等危险赋值点，以及src/href属性拼接、hidden input动态写入、富文本直插DOM等高危交汇位置。
前端安全测试里，HTML漏洞排查不是“扫一遍源码就完事”，而是要盯住数据从哪里来、到哪里去、中间有没有被污染。绝大多数高危问题（XSS、框架嵌入、隐藏字段篡改）都发生在用户输入与DOM渲染的交汇点，且几乎全部绕过客户端验证就能触发。
怎么快速定位可能被注入的HTML输出点
关键不是找所有<input>或<img>标签，而是找那些“值来自不可信源”的地方。重点关注以下三类位置：
-
innerHTML、outerHTML、document.write()被赋值的地方，尤其是右侧变量含location.search、location.hash、document.referrer或 API 返回的 JSON 字段 -
<img src="...">、<a href="...">、<script src="...">的属性值由 JS 拼接生成，且未校验协议（如允许javascript:或data:） - 模板字符串或 DOM 插入逻辑中直接拼接用户输入，例如：
el.innerHTML = `<div>` + userInput + `</div>`
用浏览器开发者工具的 Sources 面板全局搜索这些关键词，比肉眼扫 HTML 更快。发现后立刻在 Console 里模拟输入 <img src=x onerror=alert(1)>，看是否执行。
为什么改了 hidden input 就能出问题
因为很多业务逻辑把权限、价格、ID 等关键状态直接塞进 <input type="hidden" name="price" value="99">，然后服务端无条件信任。这不是 HTML 本身有漏洞，而是它成了攻击者篡改业务参数的“合法通道”。
立即学习“前端免费学习笔记（深入）”；
排查时别只看 value 值是否被改——更要检查：
- 该字段是否由 JS 动态写入（比如从 URL 参数或 localStorage 读取后填入），意味着攻击者可提前污染源头
- 提交后服务端是否校验该值的合理性（例如价格是否在合理区间、ID 是否属于当前用户）
- 有没有签名机制：比如
<input type="hidden" name="price_sig" value="hmac-sha256(...)">，服务端必须验证
只要服务端没做校验，哪怕你把 value 改成 -999999，订单也可能照常生成。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
iframe 和 frame-ancestors 头不匹配就是 Clickjacking 风险
仅看 HTML 里有没有 <iframe> 标签没用。真正的问题是：这个页面能不能被别人用 <iframe src="your-site.com"> 嵌入？如果能，且没防御，就构成 UI 重绘攻击基础。
检测方法分两步：
- 用浏览器开发者工具的 Network 面板查看任意响应头，确认是否包含
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none' - 手动建一个测试 HTML 文件，里面放
<iframe src="https://yoursite.com/login"></iframe>，打开看是否能加载成功
注意：如果响应头里写了 frame-ancestors 'self'，但页面里又用了 <iframe sandbox=""> 加载外部资源，这种混合策略容易出错，得单独验证 sandbox 权限是否被过度放宽。
富文本内容插入 DOM 是最隐蔽的 XSS 温床
富文本编辑器（如 TinyMCE、Quill）返回的 HTML 字符串，如果直接用 innerHTML 插入，等于把解析权完全交给浏览器——而攻击者早就研究透了各种绕过过滤的写法。
测试时不要只试 <script>，重点打这些点：
<img src="x" onerror="fetch('/api/steal?cookie='+document.cookie)">-
<svg><script>alert(1)</script></svg>（部分编辑器放过 SVG） -
<a href="javascript:alert(1)">click</a>（检查是否过滤javascript:协议） - 用
<script></script>这类 HTML 实体编码绕过前端正则过滤
真正安全的做法不是靠前端“过滤干净”，而是服务端存储前做白名单净化（如只保留 <p>、<strong>、<img> 及其有限属性），前端渲染时再用 textContent 显示纯文本，或用 DOMPurify.sanitize() 处理 HTML 字符串——这两步缺一不可。
最容易被忽略的是：AJAX 返回的 HTML 片段、服务端模板渲染的初始 HTML、以及 localStorage 中缓存的用户数据，这三处来源一旦混入未处理的用户输入，就会在 DOM 操作中突然爆发。它们不像表单字段那么显眼，但危害更大。
