快速定位HTML用户可控输出点需重点检查三类高危模式：模板变量插值（如{{user_input}}）、JS动态写入（如innerHTML=data.name）、服务端渲染未转义内容；结合开发者工具Elements面板搜索危险关键词，并手动测试典型XSS payload。
直接看源码和请求链路，比等扫描工具报错更早发现问题。HTML本身不执行逻辑，但它是XSS、SSRF、CSP绕过、资源劫持的入口点，漏洞往往藏在动态拼接、用户可控字段和缺失防御策略里。
怎么快速定位用户可控的HTML输出点
重点盯三类地方：模板变量插值、JS动态写入、服务端渲染时未转义的内容。比如 <div>{{ user_input }}</div>、document.write(userInput)、innerHTML = data.name 这些都是高危模式。
- 用浏览器开发者工具的 Elements 面板搜索
<script>、javascript:、data:、vbscript:，看是否出现在 src/href/srcset 等属性中 - 检查所有带
user_、input_、param、query、name、url等命名的变量是否直接进了 HTML 上下文 - 对表单提交后回显内容（如搜索关键词、评论、错误提示）做手动测试：输入
<img src=x onerror=alert(1)>，看是否触发弹窗
src/href 属性里为什么不能直接拼接用户输入
因为攻击者可以注入 javascript:alert(1)、data:text/html;base64,PGJvZHk+YWxlcnQoMSk8L2JvZHk+ 或 SSRF 类型的内网地址（如 http://127.0.0.1:8080/admin），导致 XSS 或服务端请求伪造。
- 必须校验协议白名单：只允许
http、https、//（协议相对）、/（路径相对） - 禁止
javascript:、vbscript:、data:（除非业务强依赖且已做内容过滤） - 对域名做白名单控制，比如只允许
cdn.example.com、images.example.com - 服务端生成 URL 时，优先用 ID 映射（如
/api/image/12345），而不是让用户传完整 URL
CSP 头没配或配错等于没防XSS
光靠前端转义不够，CSP 是最后一道防线。很多项目只加了 script-src 'self'，却漏掉 img-src、connect-src 或没禁用 'unsafe-inline'，结果依然可被绕过。
立即学习“前端免费学习笔记（深入）”；
- 必须设置
default-src 'none'，再按需放开：比如img-src 'self' https: data:（若需 base64 图片） -
script-src禁止'unsafe-inline'和'unsafe-eval'；内联脚本改用nonce或hash - 配合
report-uri或report-to收集违规行为，别只写 header 不看报告 - CDN 或代理层可能覆盖或删除 CSP 响应头，部署后用 curl -I 验证实际返回值
HTML 注释和隐藏字段也可能是信息泄露口
开发常把调试信息、API 路径、密钥片段、内部状态写进注释或 <input type="hidden">，这些对爬虫和手动审计者完全透明。
- 构建流程中自动移除 HTML 注释（Webpack 的 html-webpack-plugin 可配
minify.removeComments: true） - 禁止在
value属性里存敏感数据，比如<input type="hidden" name="token" value="abc123">—— token 应由后端签发并校验，前端只负责透传 - 后端返回 JSON 数据时，避免把数据库字段名、错误堆栈、环境变量名直接暴露在 HTML 的
data-属性里
真正难的不是写对一行 escapeHtml()，而是确保每个动态插入点都走同一套上下文感知的编码规则，并让 CSP、输入校验、服务端处理形成闭环。漏掉任意一环，攻击者就可能从一个图片链接跳到整个会话劫持。
