HTML本身无漏洞，真正风险在于用户输入被不当拼入HTML上下文导致XSS；需重点检测带参URL、表单、AJAX响应等动态环节，而非静态HTML文件。
HTML本身不是漏洞来源，真正出问题的是你用HTML承载的内容、解析它的环境，以及你如何处理用户输入。所有所谓“HTML漏洞”，本质都是XSS、模板注入、DOM操作失当或解析器配置错误的外在表现。
为什么直接检测HTML文件几乎没意义
静态HTML文件（如 index.html）不执行逻辑、不接收输入、不调用JS，单独扫描它不会发现XSS或注入问题。真正危险的是那些把用户数据拼进HTML上下文的环节——比如后端模板渲染、前端JS动态写入、服务端HTML解析（如用 gumbo-parser 处理富文本）、甚至邮件模板生成。
- 常见误操作：用
curl -s http://site.com/page | grep "<script>"判断是否存在XSS —— 这只能看到“有没有script标签”，完全无法判断是否可执行、是否被转义、是否在DOM中被重写 - 真正要检测的，是带参数的URL（如
/search?q=xxx）、表单提交入口、AJAX响应体、富文本保存接口 - 如果你在用服务端HTML解析器（如
gumbo-parser），必须检查是否启用了stop_on_first_error=false且未限制max_errors，否则恶意构造的畸形HTML可能触发解析器崩溃或内存耗尽
DOM型XSS的典型触发点与验证方式
这类漏洞不经过服务器，纯前端JS操作DOM时引入不可信数据，浏览器直接执行。最常出现在 location.hash、location.search、document.referrer 或第三方SDK回调中。
- 快速验证：打开控制台，执行
document.getElementById('target').innerHTML = '<img src="https://img.php.cn/" alt="HTML漏洞检测与修复实战指南">'，看是否弹窗；再试textContent对比，确认是否绕过 - 高频危险函数：
innerHTML、outerHTML、document.write()、eval()、setTimeout(string)、setInterval(string) - 修复原则：永远优先用
textContent替代innerHTML；若必须插HTML，用已知安全的库（如 DOMPurify）做白名单过滤，而不是简单 replace / strip
服务端HTML解析器的安全配置要点（以 gumbo-parser 为例）
如果你在后端用 gumbo-parser 解析用户提交的HTML（如论坛发帖、CMS富文本），默认配置可能不足以抵御恶意构造的输入。
立即学习“前端免费学习笔记（深入）”；
- 必须显式设置
options.max_errors = 100，防止超长错误列表导致内存暴涨 - 启用
options.stop_on_first_error = true可在遇到第一个严重语法错误时终止解析，避免后续不可控行为 - 自定义分配器中需校验
size上限，例如拒绝单次申请 > 1MB 的内存，防爆破式分配 - 不要依赖解析器自动修复 malformed HTML —— 它的“容错”可能正是攻击者利用的入口，比如嵌套过深的标签、超长属性名、非法实体引用
最容易被忽略的一点：HTML安全不是“加个转义函数”就完事。它取决于上下文——是在HTML文本节点？属性值？JS字符串？CSS内容？每个上下文都有唯一正确的编码方式。用错地方，htmlspecialchars() 和 DOMPurify.sanitize() 都会失效。
