跨站脚本攻击（XSS）长期以来一直是 Web 安全领域最棘手的问题之一。在过去的近十年间，CWE-79（跨站脚本）始终位列最常见的 Web 漏洞前三名。Mozilla 在 2009 年牵头制定内容安全策略（CSP）标准，开启了浏览器端 XSS 防护的先河。然而 CSP 因其对现有架构改动要求高、持续维护成本大等问题，未能得到广泛采用。面对这一困境，Firefox 148 首次实现了标准化的 Sanitizer API，为 Web 开发者提供了一种内建的 HTML 净化方案，从根本上降低了 XSS 攻击的风险。
从 InnerHTML 到 SetHTML 的安全迁移
传统上，开发者使用 innerHTML 属性将 HTML 字符串插入到 DOM 中，这种方式简单直接但没有任何安全防护。当处理用户输入或来自外部的不可信数据时，攻击者可以轻易注入恶意脚本标签或事件处理器属性，从而实现 XSS 攻击。Firefox 148 引入的 Element.setHTML() 方法彻底改变了这一局面：它在解析 HTML 的同时自动执行净化操作，将可能存在风险的代码片段移除，然后才将安全的结果插入到 DOM 树中。
这种设计带来的最直接好处是开发者只需进行最微小的代码改动即可获得显著的安全提升。原本使用 el.innerHTML = userSuppliedHtml 的地方可以直接替换为 el.setHTML(userSuppliedHtml)，即可获得内置的 XSS 防护能力。根据 Mozilla 官方示例，一段包含恶意 onclick 属性的 HTML 字符串在经过 setHTML() 处理后，危险属性将被完全移除。例如：
document.body.setHTML(`<h1>Hello my name is <img src="x" onclick="alert('XSS')">`);
经过净化后，DOM 中仅保留 <h1>Hello my name is</h1>，攻击者精心构造的 img 标签及其 onclick 事件处理器被彻底清除。
默认安全配置的工程细节
setHTML() 方法默认采用标准化的 Sanitizer 配置，这一配置经过精心设计，允许被认为是安全的 HTML 元素和属性通过，同时自动移除可能导致 XSS 的危险内容。具体来说，<script> 元素、事件处理属性（如 onclick、onerror、onload）、javascript: 协议的链接以及各类可能导致脚本执行的属性都会被默认移除。
值得注意的是，即使开发者提供了自定义的 Sanitizer 配置，setHTML() 仍会执行一道隐式的安全过滤。W3C 规范中明确规定了一个强制性的 Sanitizer.removeUnsafe() 步骤，这意味着即使你的自定义规则存在疏漏，浏览器层面的安全底线也不会被突破。这种「安全默认」的设计哲学贯穿于整个 API 的实现之中，为开发者提供了双重保护机制。
自定义配置与灵活控制
在某些业务场景下，默认的净化规则可能过于严格或过于宽松。为此，setHTML() 允许开发者通过传入配置对象来自定义净化行为。配置项可以精确控制哪些元素、属性、注释应当保留，哪些应当移除。Mozilla 提供了 Sanitizer API 在线 Playground，开发者可以在其中直观地测试不同配置的实际效果。
对于确实需要插入危险内容的极少数场景（例如需要保留事件处理器作为应用内部功能的一部分），Firefox 同样提供了 Element.setHTMLUnsafe() 方法作为后备选项。但官方建议仅在完全信任输入来源的情况下使用该方法，日常处理不可信数据时应优先选择 setHTML()。
Trusted Types 策略的协同部署
Firefox 148 同时引入了 Trusted Types API 的完整支持，这为大型应用的统一安全策略提供了基础设施。当两者结合使用时，站点可以配置一个严格的策略：仅允许通过 setHTML() 插入 HTML，同时阻止其他不安全的 DOM 写入操作（如直接使用 innerHTML）。这种策略导向的部署方式使得应用可以在不编写复杂自定义策略的情况下，逐步完成向安全 API 的迁移，同时有效防止未来可能出现的 XSS 回归漏洞。
对于需要处理大量用户生成内容的 Web 应用而言，采用 setHTML() 配合 Trusted Types 策略是一种低成本、高收益的安全加固方案。它无需安全团队专门编写复杂的净化逻辑，也不要求对现有架构进行大规模重构，只需在代码中替换 API 调用并启用相应的安全策略即可实现。
工程落地的关键参数建议
在生产环境中部署 setHTML() 时，建议遵循以下工程实践：首先，将所有处理不可信用户输入的代码路径作为优先迁移对象，这类场景通常包括评论区、用户资料页、富文本编辑器输出等；其次，对于需要保留特定安全元素的场景（如允许 <a> 标签的 href 属性但禁止 javascript: 协议），应在自定义配置中显式声明允许列表；最后，务必在 CI/CD 流程中加入对 Trusted Types 策略的检测，确保新增代码不会绕过安全检查。
数据来源：Mozilla Hacks 官方博客（https://hacks.mozilla.org/）