防止XSS的DOMPurify库在富文本编辑器中集成

在富文本编辑器中直接集成DOMPurify库，是当前Web前端开发中防止XSS攻击最有效、最可靠的策略之一。核心思路非常简单：在将用户提交的、包含HTML标签的富文本内容插入到页面DOM之前，先将其通过DOMPurify进行“净化”，剥离所有可能执行恶意脚本的危险代码，只保留安全的、预设允许的HTML标签和属性。这相当于在不可信的用户输入和你的应用DOM之间，设置了一道严格的安全检查关卡。

为什么富文本编辑器是XSS攻击的重灾区？

传统的文本输入框，我们可以通过转义特殊字符（如将<转义为<）来轻易防御XSS。但富文本编辑器的本质是允许用户输入格式化的HTML，并期望这些HTML能被浏览器正常渲染。如果你直接将用户输入的"加粗<script>恶意代码</script>"插入页面，浏览器会忠实执行其中的脚本。编辑器本身（如Quill.js、TinyMCE、wangEditor）提供的API通常只负责生成HTML，而不会对内容的安全性做充分担保。攻击者可以通过粘贴、源码编辑、甚至利用编辑器某些功能（如自定义样式、插入链接的onmouseover事件）来注入脚本。因此，对编辑器输出的HTML进行二次过滤，不是可选项，而是必选项。

DOMPurify的核心优势：安全、可配置、轻量

市面上有多种HTML净化方案，但DOMPurify之所以成为行业首选，源于其独特的设计。它不是一个简单的正则表达式过滤器（正则难以应对HTML复杂的嵌套和上下文）。DOMPurify使用浏览器真正的DOM解析器（或兼容的模拟器）来解析输入的HTML字符串，将其转换为DOM节点树，然后根据一个极其严格的白名单列表，遍历整个树，只保留“安全”的节点和属性，最后将净化后的DOM树序列化回干净的HTML字符串。这个过程确保了净化结果的语法正确性，并且能防御各种绕过技巧，如畸形标签、unicode混淆、未闭合标签攻击等。它非常轻量（核心压缩后约20KB），且提供了高度灵活的配置API，允许你精确控制允许的标签、属性、甚至CSS样式。

如何在主流富文本编辑器中集成DOMPurify

集成模式通常是“输入净化”或“输出净化”。更推荐的是“输出净化”，即在编辑器内容提交或需要渲染时，对生成的HTML进行净化。这保证了无论内容来自用户输入、数据库读取还是第三方导入，在进入你的DOM前都经过同一道安全门。以下是具体步骤和代码示例。

第一步：安装与引入DOMPurify

你可以通过npm安装："npm install dompurify"。在项目中，通常需要配合一个解析器环境。对于浏览器端项目：

import DOMPurify from 'dompurify';

对于Node.js服务器端环境（如Next.js、Nuxt.js的SSR），你需要引入JSDOM来创建一个window对象：

import { JSDOM } from 'jsdom';
import DOMPurify from 'dompurify';

const window = new JSDOM('').window;
const purify = DOMPurify(window);

第二步：基础净化与配置

最基本的用法是调用"DOMPurify.sanitize()"方法。

const dirtyHtml = `正常内容`;
const cleanHtml = DOMPurify.sanitize(dirtyHtml);
console.log(cleanHtml); // 输出：正常内容

默认的白名单已经非常严格，移除了"<script>"、"onerror"等危险内容。但富文本编辑器往往需要更多格式支持，这就需要自定义配置。DOMPurify的第二个参数是一个配置对象。

const config = {
  ALLOWED_TAGS: ['p', 'strong', 'em', 'u', 'h1', 'h2', 'h3', 'ul', 'ol', 'li', 'a', 'img', 'br', 'span'],
  ALLOWED_ATTR: ['href', 'target', 'title', 'src', 'alt', 'class', 'style'],
  ALLOWED_URI_REGEXP: /^(?:(?:(?:f|ht)tps?|mailto|tel):)/i // 只允许特定协议的URL
};
const editorOutput = `标题链接`;
const safeHtml = DOMPurify.sanitize(editorOutput, config);
// 结果：标题链接// `javascript:`协议和`onclick`属性被移除，`style`属性被保留（但内部内容也会被净化）。

第三步：与具体编辑器结合（以Quill和TinyMCE为例）

对于Quill.js，你可以在获取HTML内容时进行净化。假设你有一个表单提交逻辑：

// 获取Quill编辑器实例的HTML内容
const dirtyDelta = quill.root.innerHTML; // 或者 quill.getSemanticHTML()
// 进行净化
const cleanHTML = DOMPurify.sanitize(dirtyDelta, {
  ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'u', 'h1', 'h2', 'h3', 'blockquote', 'ul', 'ol', 'li', 'a', 'img'],
  ALLOWED_ATTR: ['href', 'target', 'rel', 'src', 'alt', 'title', 'class'],
  // 强制所有链接添加 rel="noopener noreferrer"，增强安全
  ADD_ATTR: { 'a': ['rel'] },
  ADD_TAGS: ['iframe'], // 如果你需要允许iframe
  ADD_ATTR: ['allow', 'allowfullscreen', 'frameborder', 'scrolling'] // 为iframe添加属性
});
// 然后将cleanHTML提交到服务器或插入到展示区域
document.getElementById('safe-container').innerHTML = cleanHTML;

对于TinyMCE，你可以在初始化编辑器时，设置其"setup"选项，在获取内容时进行拦截净化：

tinymce.init({
  selector: '#myEditor',
  setup: function(editor) {
    editor.on('PostProcess', function(e) {
      if (e.content) {
        e.content = DOMPurify.sanitize(e.content, customConfig);
      }
    });
    // 或者更直接地，在提交时处理
    editor.on('GetContent', function(e) {
      if (e.save) {
        const original = tinymce.activeEditor.getContent({format: 'html'});
        e.content = DOMPurify.sanitize(original, customConfig);
      }
    });
  }
});

高级配置与注意事项

DOMPurify的强大之处在于其精细的控制能力。例如，你可以使用"ALLOW_DATA_ATTR: false"来禁止所有"data-*"属性（它们有时会被用于隐藏攻击载荷）。使用"SAFE_FOR_JQUERY: true"可以确保输出对jQuery的".html()"方法也是安全的。对于"style"属性，DOMPurify默认会进行CSS解析，只允许安全的CSS属性值（如阻止"url(javascript:...)"）。你甚至可以通过钩子（hooks）系统在净化过程中进行更底层的干预，例如对所有图片URL添加CDN前缀，或记录被移除的恶意内容。

DOMPurify.addHook('afterSanitizeAttributes', function(node) {
  // 强制所有链接在新窗口打开并添加安全属性
  if (node.tagName === 'A') {
    node.setAttribute('target', '_blank');
    node.setAttribute('rel', 'noopener noreferrer');
  }
  // 为所有图片添加loading="lazy"属性
  if (node.tagName === 'IMG') {
    node.setAttribute('loading', 'lazy');
  }
});

需要特别注意的一个陷阱是“净化后二次污染”。绝对不要对净化后的字符串再次进行任何字符串拼接或未经转义的操作。"DOMPurify.sanitize()"返回的是可以直接用于"innerHTML"或"dangerouslySetInnerHTML"的字符串。如果你将它与其他字符串拼接，整个拼接结果又需要被当作HTML解析时，你必须对拼接部分进行转义，或者将整个新字符串再次通过DOMPurify净化。

服务器端与客户端双重净化策略

一个更健壮的架构是实施“纵深防御”。在客户端集成DOMPurify，可以提供即时反馈和减少无效请求。但绝不能仅依赖客户端净化，因为攻击者可以绕过你的前端JavaScript直接向服务器API发送恶意载荷。因此，在服务器端（使用Node.js的DOMPurify或类似库如Python的"bleach"）必须对接收到的富文本内容再次进行完全相同的净化。两套净化逻辑的白名单配置必须保持一致，确保攻击在任何一层都无法得逞。

性能考量与替代方案

DOMPurify的性能在绝大多数场景下都足够优秀。但对于处理极端大量或非常复杂的HTML（如整本书的章节），在客户端进行净化可能会造成界面卡顿。解决方案可以是：

1. 将净化工作移至Web Worker线程；

2. 在服务器端处理；

3. 对内容进行分块净化。虽然DOMPurify是首选，但在某些极简场景下，如果你只需要支持非常有限的标签（如仅加粗、斜体），使用一个经过严格审计的、基于白名单的正则替换方案也未尝不可，但其维护成本和潜在漏洞风险远高于使用成熟的DOMPurify。

总结来说，将DOMPurify集成到富文本编辑器工作流中，是一个将安全性从“期望用户善良”转变为“默认安全”的关键步骤。它通过一个经过千锤百炼的白名单模型，在提供丰富格式支持的同时，从根本上切断了XSS攻击的路径。正确配置并实施客户端与服务器端的双重净化，是现代Web应用处理用户生成富文本内容的黄金标准。

防止XSS的DOMPurify库在富文本编辑器中集成

服务指南

帮助中心