DOM型XSS漏洞源于前端脚本将用户可控数据未经安全处理直接写入innerHTML、eval等敏感DOM位置，完全在浏览器端执行，不依赖服务器反射或存储。
直接看输出点和数据流向，不依赖“有没有用框架”或“前端校验是否完善”这种模糊判断——XSS、模板注入、框架嵌入等漏洞，90%以上都源于用户输入未经处理就进了危险上下文。
怎么快速定位innerHTML等DOM写入点
浏览器开发者工具的 Sources 面板里全局搜索以下关键词，逐个点开确认是否接收了用户可控数据：
-
innerHTML、outerHTML、document.write -
insertAdjacentHTML、setHTML（某些UI库封装方法） -
eval、setTimeout、setInterval的第一个参数是拼接字符串
特别注意动态生成的节点：比如 document.createElement('div') 后又调用 el.innerHTML = data，axe 或 ESLint 插件通常扫不到这种组合。如果数据源来自 location.search、location.hash、localStorage 或 fetch 响应体，必须人工验证是否转义。
检查模板引擎是否把用户输入当代码执行
不是所有模板渲染都安全。关键看「模板内容是否运行时拼接」，而不是「用了什么引擎」：
立即学习“前端免费学习笔记（深入）”；
- FreeMarker 中查
new Template(…, new StringReader(userInput))或include路径含request.getParameter - art-template 查
template.compile(userInputString)，而非template.compile(templatePath) - 所有引擎中，
${userInput?eval}、{{@userInput}}、{{= userInput}}这类语法若出现在用户可控字段渲染处，就是高危信号
默认 HTML 转义（如 {{data}}）只防 XSS，不防模板注入；它把 <script></script> 变成文本，但拦不住 ${1+1} 执行。
响应头和iframe配置是否暴露Clickjacking风险
打开浏览器开发者工具的 Network 面板，刷新任意页面，点开任意 HTML 响应，看 Response Headers 里有没有这两个关键项：
-
X-Frame-Options: DENY或SAMEORIGIN（旧标准，但兼容性好） -
Content-Security-Policy: frame-ancestors 'none'或'self'（新标准，优先级更高）
如果都缺失，再检查 HTML 源码中是否有 <iframe src="..."> 且没加 sandbox 属性，或 sandbox 值为 ""（空字符串代表全放开）。这类配置错误会让页面极易被嵌入恶意站点完成 UI 重绘攻击。
为什么静态扫描工具总漏掉真实漏洞
因为它们看不到运行时状态和条件分支：
-
axe DevTools扫不到v-if="false"或*ngIf=false里的 DOM，哪怕里面写了innerHTML -
HTMLHint根本无法判断<button aria-label="删除">是否在重复 ID 的上下文中，也识别不了alt=""在图标按钮里是否合法 - 所有通过
fetch动态插入的节点，若没触发渲染，axe和W3C Validator都看不见
真正卡住人的从来不是工具不会配，而是以为“扫描无报错=安全”。实际漏洞常藏在 JS 动态创建 + 用户输入 + 未转义写入这个三段链条里，必须手动断点追踪数据流走到哪一步开始失控。
