DOM型XSS入口点需从JS读取用户输入处查起，重点监控location.hash、location.search等数据源及innerHTML、document.write等危险sink操作。
HTML页面本身不执行逻辑，但它是整个Web安全链的起点——XSS、URL跳转、锚点滥用、图片src注入等漏洞，几乎都始于HTML结构或其与JS/CSS的交互方式。直接看代码和浏览器行为，比依赖扫描工具更高效。
如何快速定位DOM型XSS入口点
DOM型XSS不经过服务器，纯前端触发，所以必须从JS读取用户输入的位置开始查。重点盯住这些数据源：location.hash、location.search、document.referrer、localStorage、sessionStorage，再顺藤摸瓜找“sink”（写入DOM的位置）。
-
innerHTML、outerHTML、document.write()是高危操作，只要参数含上述任一数据源，基本可判定存在风险 -
eval()、setTimeout()、setInterval()接收拼接字符串时同样危险，哪怕只用于解析JSON也要警惕 - 用浏览器开发者工具的 Sources 面板全局搜索
location.hash或.href =，配合断点观察变量值是否被原样插入 - 测试时直接在URL后加
#<script>alert(1)</script>或?q=<img src=x onerror=alert(1)>，刷新后看是否弹窗或DOM中出现未转义标签
检查图片src属性是否引入SSRF或XSS风险
<img src="..."> 看似无害，但若 src 值来自用户输入或后端模板变量，就可能成为攻击跳板。关键不是“图片能不能加载”，而是“浏览器会不会执行其中内容”。
- 禁止
javascript:、data:（尤其是data:text/html）、vbscript:等伪协议，它们可在某些上下文中触发脚本执行 - 对上传类头像或富文本中的图片，服务端必须重写URL——不能直接回显用户提交的完整URL，而应生成带签名的CDN路径，如
https://cdn.example.com/img/abc123.jpg?sig=xyz - 前端渲染前，可用正则粗筛：
/^https?:\/\//i.test(src)仅是第一步，真正要靠服务端白名单校验协议+域名 - CSP策略中必须明确设置
img-src 'self' https:，否则即使HTML写了安全URL，攻击者仍可通过内联style或base标签绕过
锚点跳转（#id）被滥用的典型迹象
锚点本身合法，但当它被JS读取并用于动态显示隐藏内容、加载模块或修改DOM时，就可能失控。这类问题往往不会报错，却会悄悄改变页面语义或暴露敏感区域。
立即学习“前端免费学习笔记（深入）”；
- 打开开发者工具，在 Elements 面板里搜
display: none或visibility: hidden的元素，再检查它们是否有id；然后看URL中#xxx是否恰好匹配这些id - 搜索JS中所有
location.hash的读取位置，尤其注意是否用它拼接字符串后赋给innerHTML或触发fetch() - CSS中若存在类似
#admin-panel:target { display: block; }的规则，且该id="admin-panel"元素默认隐藏，就等于把后台入口暴露给了任意URL片段 - 真实案例中，攻击者发一个链接
https://site.com/page#user-data:target，就能让本该隐藏的用户数据块突然可见
排查链接跳转漏洞的关键检查项
跳转漏洞常伪装成“功能正常”，直到钓鱼邮件里出现带恶意参数的链接。它的本质是信任了未经校验的用户输入来控制 window.location.href 或 <a href="..."> 的目标。
- 检查所有含
url=、redirect=、next=、return_to=等参数的URL，看后端是否做了域名白名单校验（不只是简单匹配example.com，还要防evil.com.example.com） - 前端JS中若出现
window.location.href = userInput或el.setAttribute('href', userInput)，且userInput来自URL参数或本地存储，就是高危信号 - 用Burp Suite或浏览器Network面板抓包，改写跳转参数为
https://evil.com，观察响应状态码是否仍是302，且Location头未被拦截 - 即使跳转被拦截，也要看错误页是否泄露内部路径或堆栈信息——这属于信息泄露，同样是漏洞
最易被忽略的是：HTML语法错误（如标签未闭合）本身虽不直接导致安全问题，但会干扰浏览器解析，使CSP失效、script标签错位、甚至让XSS payload意外逃逸。所以每次上线前，用W3C Validator跑一遍原始HTML，比等渗透报告更早发现问题。
