关键在于识别将用户输入变为可执行上下文的HTML结构或行为，如<script>、innerHTML、document.write、eval、location.href等危险操作；需重点排查内联事件（onerror/onclick）、高危标签（iframe/script）及动态DOM写入点（如.html()、v-html、dangerouslySetInnerHTML），并按输出上下文（HTML主体、属性、JS字符串、URL）实施精准转义。
HTML网页安全性测试不是“扫一遍就完事”，关键在于识别哪些HTML结构或行为会把用户输入变成可执行上下文。绝大多数XSS、点击劫持、开放重定向等漏洞，都始于对<script>、innerHTML、document.write、eval、location.href等危险操作的不加防护使用。
怎么快速定位HTML中可能触发XSS的DOM写入点
不要通读所有JS文件——先看页面加载后实际发生了什么。打开浏览器开发者工具，切换到「控制台」，执行console.dir(document.querySelectorAll('*[onerror], *[onclick], *[onload], iframe, script, object, embed'))，能立刻列出所有内联事件和高危标签。再配合「网络」面板过滤XHR和fetch请求，重点检查返回内容是否被element.innerHTML = response或$('...').html(...)直接插入。
- 特别注意
data-属性值被JS读取后拼接到HTML字符串的场景，比如<div data-user-input="<img src=x onerror=alert(1)>"></div>+el.innerHTML = el.dataset.userInput -
document.write在现代页面中虽少，但若出现在异步加载的广告或统计脚本中，且参数来自URL（如utm_content），极易触发反射型XSS - jQuery的
.html()、.append()、.before()等方法，只要参数含用户可控内容，且未经$.text()或textContent转义，就是高风险点
为什么innerHTML比textContent更危险
因为innerHTML会解析字符串为DOM节点，而textContent只当纯文本处理。服务端返回{"name": "<img src=x onerror=alert(1)>"}，前端若用el.innerHTML = data.name，就会执行onerror；换成el.textContent = data.name，页面只会显示那段文字本身。
- 常见误用：把JSON响应字段直接塞进
innerHTML，尤其在渲染评论、通知、搜索建议等动态列表时 - 框架也不能全信：React默认对
{data.name}做转义，但显式使用dangerouslySetInnerHTML就等于主动绕过防护 - Vue中
v-html同理，必须确保绑定值来自可信源或已由后端完成HTML实体编码（如<script></script>）
如何验证HTML输出是否做了正确编码
编码不是“加个escape函数”就万事大吉。要按上下文区分：HTML主体、HTML属性、JavaScript字符串、URL参数，各自需要不同编码方式。最简单验证法：在输入框/URL参数里提交"<script>alert(1)</script>，观察它在页面中是被原样显示，还是被渲染执行，或是变成<script>alert(1)</script>。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 如果显示为
<script>alert(1)</script>（即标签被转义），说明HTML主体编码生效 - 如果出现在
<input value="xxx">中且没闭合引号，说明属性值编码缺失或不完整 - 如果出现在
onclick="doSomething('<script>')"中并导致JS语法错误，说明JS字符串编码没做或用了错误方式（应为\u003cscript\u003e而非） - 避免依赖浏览器自带XSS Filter（如Chrome的XSS Auditor），它早已被弃用且不可靠
绕过前端验证的常见手法与测试重点
HTML表单的required、pattern、maxlength、type="email"等属性，仅用于提升用户体验，对攻击者毫无约束力。真正要测的是服务端是否重复校验，以及客户端逻辑是否被滥用。
- 用Burp Suite或浏览器控制台直接修改
form.action指向其他地址，或删除disabled属性后提交隐藏字段 - 抓包重放时，把
Content-Type: application/json改成text/plain，看服务端是否仍按JSON解析并触发类型混淆 - 检查
<input type="hidden" name="role" value="user">这类字段，修改为admin后提交，确认服务端是否校验权限而非仅依赖前端传值 - Cookie中的
is_admin=true、level=99等字段，手动改写后发请求，测试水平越权可能性
HTML安全测试最易被忽略的一点：很多漏洞不出现在主页面，而是藏在AJAX回调、第三方SDK注入的iframe、或者<meta http-equiv="refresh">跳转逻辑里。别只盯着index.html，得顺着网络请求链一路跟下去，直到数据真正落进DOM的那一刻。
