html页面xss主因是未净化的用户输入直通dom：所有innerhtml、document.write等动态插入点必须审查来源，优先用textcontent或dompurify处理；src/href属性需协议白名单校验；csp须覆盖关键指令且禁用unsafe-inline/eval；dom型xss需人工追踪数据流路径。
HTML页面本身不执行逻辑，但它是XSS、SSRF、CSP绕过等攻击的主战场。排查关键不是“有没有漏洞”，而是“哪些输出点未经净化就直通DOM”。
检查所有动态插入HTML的位置
用户输入一旦被拼进innerHTML、outerHTML、document.write()或insertAdjacentHTML()，就极可能触发XSS。这类操作在富文本编辑器、评论渲染、搜索关键词高亮、URL参数回显等场景高频出现。
- 用浏览器开发者工具的Elements面板搜索
innerHTML =、.write(、insertAdjacentHTML等字符串，逐行确认右侧变量是否来自location.search、location.hash、localStorage、fetch()响应等不可信源 - 若必须插入HTML，优先改用
textContent；若真需保留格式，必须用DOMPurify.sanitize()处理后再赋值 - 警惕模板字符串拼接：
el.innerHTML = `<div>${userInput}</div>`和直接赋值一样危险，ES6模板无法自动转义
审查所有src/href属性的动态赋值
<img src="">、<script src=""></script>、<a href=""></a>这些属性若由JS动态设置，且值含用户输入，就可能被注入javascript:、data:甚至恶意CDN地址。
- 全局搜索
.src =、.href =，重点看右侧是否经过协议白名单校验（只允许https://、http://、/开头） - 禁止接受
javascript:、vbscript:、data:text/html,等伪协议；data:image/png;base64,可放行，但需限制base64长度防DoS - 上传头像/图片时，前端不应直接使用用户传的URL，而应由后端返回经签名的、限定域名的临时链接
验证CSP策略是否覆盖关键指令
CSP不是万能，但没它等于裸奔。仅靠script-src 'self'远远不够——img-src、connect-src、base-uri缺失会导致XSS利用面扩大。
- 在Network面板查看响应头中是否有
Content-Security-Policy，用在线CSP检查器（如csp-evaluator.withgoogle.com）验证语法有效性 - 确保
default-src 'none'或至少script-src和object-src明确禁止'unsafe-inline'和'unsafe-eval' - 若用
nonce-或hash-机制，确认每个内联脚本都匹配，且nonce值每次请求唯一、不泄露到日志或错误信息中
识别DOM型XSS的数据流路径
DOM型XSS不经过服务器，所以Burp、ZAP扫不出来。必须人工追踪“数据从哪来→怎么加工→写到哪去”这条链路。
- 在Sources面板中搜索常见数据源：
location.search、location.hash、document.referrer、sessionStorage.getItem、postMessage监听器 - 对每个数据源，设断点，观察其后续是否流入
eval()、setTimeout()、setInterval()、Function()或任何DOM写入API - 特别注意URL参数解析函数：比如
getQueryString('next')返回值若直接用于window.location.href = next，且未校验协议和域名，就构成开放重定向
最容易被忽略的是“看似安全”的场景：比如富文本内容经后端过滤后返回，前端仍用innerHTML插入——只要过滤不彻底（如遗漏onerror在<svg></svg>里），漏洞就存在。净化必须在最终渲染前那一刻完成，且不能依赖单一手段。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
