html是xss攻击的首要落点，需检查用户输入是否未转义插入dom、是否出现在高危上下文（如innerhtml）、是否缺乏上下文感知转义、csp策略是否严格有效，以及html结构错误是否扩大攻击面。
HTML 本身不执行逻辑，但它是 XSS 攻击最直接的落点，也是前端安全防线的第一道缺口。排查隐患不是“找 bug”，而是检查用户输入是否被原样插入 DOM、是否绕过了转义、是否暴露了可被操控的上下文。
用开发者工具看 DOM 是否被污染
打开 Chrome DevTools → Elements 面板，手动在输入框或 URL 参数中提交测试载荷（如 <img src="x" onerror="alert(1)">），然后搜索该字符串是否以未转义形式出现在 HTML 源码中。重点观察：
- 是否出现在
<div> 内容区（如 <code><div>用户输入</div>）——此时需 HTML 实体编码 - 是否出现在属性值中（如
<a href="%E7%94%A8%E6%88%B7%E8%BE%93%E5%85%A5"></a>）——需额外对引号和特殊字符转义 - 是否出现在
innerHTML、document.write()或模板字符串拼接中——这些是高危操作，应改用textContent或框架的安全渲染机制 - 插入到 HTML 文本节点：用
htmlspecialchars()（PHP）、StringEscapeUtils.escapeHtml4()（Java）或等效函数 - 插入到
href、src等属性：先校验协议白名单（仅允许http://、https://、/等），再转义引号与& - 插入到
style或onxxx属性：禁止动态拼接，这类上下文几乎无法安全转义，应彻底避免 - 使用 React/Vue：确认没用
v-html或dangerouslySetInnerHTML渲染不可信内容 - 没有宽松的
script-src 'unsafe-inline'或'unsafe-eval' - 明确限制了
default-src或script-src的域名白名单（如script-src 'self' https://cdn.example.com） - 对内联事件（
onerror、onclick）和javascript:协议有显式禁止 - 通过
report-uri或report-to收集违规日志，而不是仅依赖block-all-mixed-content这类弱策略 -
<p><script>...</script></p>未闭合的<p></p>可能让后续所有内容被包裹进恶意脚本作用域 - 重复 ID 导致 JavaScript 用
getElementById()获取错元素，可能跳过校验逻辑 - 缺少
<meta charset="UTF-8">会引发字符编码混淆，让某些 XSS 载荷绕过过滤（如 UTF-7 编码） - W3C Validator 报出的
Stray end tag或Bad value错误，往往对应着可被利用的解析歧义
检查 HTML 输出是否做了上下文感知转义
服务端输出用户数据时，不能只做一次“通用转义”。不同插入位置需要不同处理：
验证 CSP 头是否覆盖关键攻击面
CSP 不是万能补丁，但能兜底拦截大部分内联脚本和非法外源加载。检查响应头中是否包含有效的 Content-Security-Policy，并确认：
别忽略 HTML 结构错误带来的间接风险
标签未闭合、错误嵌套、ID 重复等看似只是“显示异常”，但在某些场景下会放大 XSS 影响范围：
真正难防的不是 <script></script>，而是你没意识到某段“普通文本”正被插入到一个能执行 JS 的上下文中；真正容易被忽略的也不是 CSP 配置，而是那个没加引号的 href={userInput} —— 它让整个防御链条从第一环就断开了。
