XSS漏洞最直接入口是HTML中未转义的用户输入输出，需检查动态渲染区域、上下文编码差异、框架危险API使用、防嵌入策略缺失、敏感标签属性滥用及隐藏信息泄露。
检查HTML源码中是否存在未转义的用户输入输出
这是XSS漏洞最直接的入口。只要页面里有把URL参数、表单回显、API响应内容直接拼进HTML结构的地方，就极可能出问题。比如 document.getElementById('msg').innerHTML = urlParam 这类写法，等同于给攻击者开了后门。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具的 Elements 面板，搜索
<script>、onerror=、javascript:等关键词，看是否出现在动态渲染区域 - 手动构造测试载荷，如在URL中加
?name=<img%20src=x%20onerror=alert(1)>，观察是否执行 - 注意上下文：插在属性值里（
value="xxx"）和插在标签体里（<div>xxx</div>）所需的编码方式不同，不能只靠一种Payload覆盖 - 现代框架（React/Vue）默认做转义，但一旦用了
dangerouslySetInnerHTML或v-html，就得人工确保输入已净化
验证响应头与HTML中是否缺失防嵌入策略
Clickjacking不是靠代码漏洞，而是靠页面被恶意 <iframe> 套用。如果服务端没返回 X-Frame-Options 或 Content-Security-Policy: frame-ancestors，攻击者就能把你的登录页罩在透明层下诱导点击。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
curl -I http://yoursite.com/login检查响应头，确认存在且值为DENY或SAMEORIGIN - 本地建一个测试HTML，用
<iframe src="http://yoursite.com/login"></iframe>加载，看是否能成功显示（若能，说明防护失效） - 不要依赖前端JS防框架脚本（如
if (top !== self) top.location = self.location），它可被绕过，仅作辅助 - 若页面需被特定域名嵌入，必须用
frame-ancestors example.com，禁用通配符*
扫描HTML中敏感标签与危险属性的滥用
<iframe>、<object>、<embed>、<video>、<audio> 本身不危险，但它们的 src、data、onload 等属性若接受用户可控输入，就会成为XSS或SSRF跳板。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 全局搜索
src=、data=、onload=、onerror=，确认其值是否来自不可信源（如URL参数、localStorage、API返回） - 检查富文本编辑器输出内容：用
DOMParser解析后遍历节点，过滤掉iframe、script、on*属性（别只靠正则） - 对
<video>或<audio>的src做白名单校验，禁止data:、javascript:、file:协议 - 上传HTML文件时，用临时
<div>设置innerHTML后遍历子节点，检测黑名单标签和事件处理器
识别隐藏信息泄露与硬编码敏感数据
HTML不是纯展示层，它常暴露后端路径、调试开关、注释里的开发线索，甚至明文密钥。这些不会导致直接攻击，但会极大缩短攻击链路。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
view-source:或右键“查看网页源代码”，搜索<!--、DEBUG=、api_key、password、localhost、/seeyon/等关键词 - 检查
<meta name="generator">、<link rel="stylesheet" href="...v2.3.1.css">，判断技术栈版本，再查对应CVE - 留意
display:none、class="hidden"包裹的内容，有时是调试用的token或错误堆栈 - 自动化扫描工具（如
gau+grep）可批量抓取历史URL，比对是否存在遗留的测试接口（如/seeyon/htmlofficeservlet）
innerHTML 插进去；或者CSP限制了脚本，但允许 data: URI，结果被用来加载恶意HTML。检测时得顺着数据从输入→存储→输出→渲染的整条链路走一遍，而不是只盯一个点。 
