HTML层XSS风险需结合流量分析与DOM输出点定位，重点检测用户输入在innerHTML等高危操作中的处理、闭合环境及后端校验缺失；Clickjacking取决于X-Frame-Options或frame-ancestors响应头；富文本XSS绕过聚焦SVG、大小写混淆、javascript伪协议及图片EXIF注入。
HTML应用本身不执行逻辑，但它是前端攻击面的主入口；真正的漏洞往往藏在“用户输入如何被处理”和“服务端如何响应”这两个环节里。单纯扫HTML源码几乎找不到有效漏洞，必须结合流量观察、上下文分析和后端行为验证。
怎么快速定位HTML层的XSS风险点
别只盯着<script>标签，重点看数据最终落进DOM的位置和方式：
- 用浏览器开发者工具的“网络”面板，筛选
XHR或Fetch请求，检查返回的JSON或HTML片段里是否包含用户可控字段（如user_name、comment、url_param） - 搜索JS中高危操作：
innerHTML、outerHTML、document.write、eval、setTimeout（第二个参数为字符串）、location.href拼接 - 对每个疑似输出点，手工注入
<img src=x onerror=alert(1)>，提交后直接查看源码（右键→“查看页面源代码”），确认是否原样回显且未被转义 - 注意闭合环境：如果payload出现在
value="xxx"中，得先闭合引号和属性；若在<div>xxx</div>中，则需构造完整标签
表单提交为什么不能信前端校验
前端JS校验只是体验优化，绕过它只需禁用JS、改本地HTML或用curl/burp重放请求。真正要查的是后端是否做二次校验：
- 抓包修改表单字段：把
price=99改成price=-9999或price=1' OR '1'='1，看返回是否报错或逻辑异常 - 检查敏感操作是否有
CSRF token：查看表单HTML里是否存在<input type="hidden" name="csrf_token" value="...">，再尝试删掉该字段重发请求 - 测试IDOR：修改URL中
user_id=123为user_id=124，看能否越权访问他人数据 - 文件上传时，绕过前端
accept="image/*"限制，直接传shell.php，看后端是否校验文件头或扩展名
如何判断是否存在Clickjacking风险
不是看有没有<iframe>，而是看页面是否允许被嵌入——这完全取决于HTTP响应头：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 用
curl -I https://target.com/page检查是否缺失X-Frame-Options或Content-Security-Policy中的frame-ancestors - 手动建一个测试HTML：
<iframe src="https://target.com/page" sandbox="allow-scripts"></iframe>，打开后看是否能加载成功 - 特别注意登录页、密码重置页、支付确认页——这些页面一旦可被嵌入，就极易成为Clickjacking攻击目标
- 如果响应头有
X-Frame-Options: SAMEORIGIN但页面又通过postMessage与父页面通信，需额外审计消息接收逻辑是否校验来源
富文本编辑器的XSS检测关键在哪
它不像普通输入框那样简单过滤，而是主动“解析+渲染”，所以绕过点更多在解析器逻辑和上下文切换上：
- 优先试SVG和
<math>标签：<svg/onload=alert(1)>、<math href="javascript:alert(1)"></math>，很多编辑器放行这类“非脚本”标签 - 测试事件处理器大小写混淆：
<img ONERROR=alert(1)>、<p OnClick=alert(1)> - 尝试
javascript:伪协议在<a href>、<img src>、<iframe src>中是否被执行 - 上传含恶意JS的图片：把
alert(1)写进PNG文件末尾，看编辑器是否提取并执行EXIF或注释里的代码 - 检查编辑器是否开启
sanitize模式，以及白名单是否过于宽松（比如允许style属性但没过滤expression()或url(javascript:...)）
最常被忽略的一点：HTML层的问题从来不是孤立的。一个看似无害的反射型XSS，可能因为后端日志系统未转义而变成存储型；一个没设HttpOnly的sessionid Cookie，会让XSS立刻升级为账户接管。排查时必须把HTML、JS、HTTP头、后端响应串起来看，而不是只盯一个文件或一个标签。
