DOM型XSS漏洞必须在浏览器中追踪数据流定位，核心是识别不可信数据源（如location.hash、localStorage）与危险执行点（如innerHTML、eval），再通过调试验证其注入路径。
DOM型XSS漏洞无法靠服务端扫描发现，必须在浏览器里动手追踪数据流——核心是找到“谁读了用户输入”和“谁把它塞进了危险位置”。
怎么快速定位可疑的source（数据源头）
DOM型XSS的数据源全在前端运行时产生，不经过服务器。别翻后端日志，直接打开开发者工具的Console，逐个检查这些常见入口：
-
location.hash、location.search：URL中#后面或?后面的参数，比如#id=123或?q=test -
document.referrer：上一页来源，常被忽略但可能被污染 -
localStorage.getItem()、sessionStorage.getItem()：尤其注意键名含user、config、theme等暗示可配置的项 -
postMessage监听器里的event.data：单页应用间通信的高危点，容易漏审
执行console.dir({hash: location.hash, search: location.search})能一眼看清当前页面是否在读取这些值。如果返回空字符串，不代表没用——有些代码会先做if (location.hash)判断再处理，得动态改URL测试。
怎么识别危险的sink（执行点）
光有输入不够，还得看它被写到哪。以下函数/属性一旦接收未处理的source数据，基本就等于开门放狼：
立即学习“前端免费学习笔记（深入）”；
-
innerHTML、outerHTML：最常见也最危险，直接解析字符串为DOM -
document.write()：已淘汰但老项目仍有，遇之即停 -
eval()、setTimeout(string, ...)、setInterval(string, ...)：把字符串当代码执行，哪怕只拼接一个变量名也崩 -
element.setAttribute('src', ...)或element.src = ...：若赋值含javascript:或data:text/html协议，立刻触发 -
location.href = ...、location.assign(...)：跳转时若拼接了用户输入，可能触发javascript:伪协议
在Sources面板按Ctrl+Shift+F全局搜索这些关键词，重点看它们的参数是不是直接来自上面提到的source。例如：el.innerHTML = location.hash.slice(1)就是典型高危模式。
怎么验证是否真能触发（不弹alert也可能是漏洞）
别只输<script>alert(1)</script>——DOM型XSS常因上下文不同而失效。验证要分三步走：
- 先输入唯一标识符，如
test-12345，然后右键→“查看网页源代码”，搜索该字符串，确认它出现在哪个HTML位置（文本节点？属性值？script标签内？） - 根据位置选Payload：
— 在<div>xxx</div>里 → 用<img src=x onerror=alert(1)>
— 在<input value="xxx">里 → 用"><svg onload=alert(1)>
— 在<script>var a = "xxx";</script>里 → 用";alert(1);" - 用
console.log()打断点，观察source值如何一步步传到sink。例如在innerHTML = data前加debugger;，看data是否已被污染
很多DOM型XSS不会立即弹窗，而是悄悄发请求或覆盖DOM——用Network面板盯着fetch/XMLHttpRequest调用，比等alert更可靠。
为什么用textContent代替innerHTML不是万能解法
textContent确实能防大部分XSS，但它只解决“显示文本”的场景。一旦业务需要渲染富文本（比如评论里的粗体、链接），textContent就废了。这时候必须引入净化逻辑，而不是简单替换：
- 用
DOMPurify.sanitize(htmlString)处理后再塞进innerHTML，别自己写正则过滤 - 避免从
location.hash直接取值拼接URL：location.href = 'https://a.com/' + location.hash.slice(1)→ 改用new URLSearchParams(location.hash.slice(1))安全解析 - 所有
eval类调用，优先重构为JSON.parse()或查表映射，实在绕不开就加白名单校验
真正难的不是发现某个innerHTML，而是识别那些“看似安全实则危险”的链式操作——比如先用decodeURIComponent解码location.search，再split('&')，最后forEach拼成对象再赋给innerHTML。这种多层流转最容易漏掉中间某一步的过滤。
