1. 项目概述：为什么RoosterJS的安全实践如此重要？

如果你正在开发一个富文本编辑器，或者你的应用里集成了用户可编辑的HTML内容，那么“XSS攻击”这个词对你来说一定不陌生。它就像一个潜伏在暗处的幽灵，随时可能因为一个疏忽，就让你的应用门户大开。我见过太多项目，前端功能做得花里胡哨，却在安全上栽了大跟头，轻则用户数据泄露，重则整个站点被挂马。今天要聊的RoosterJS，是微软出品的一个用于构建富文本编辑器的强大框架，它本身在安全设计上就有不少考量，但框架是工具，怎么用，还得看开发者。这篇文章，我就结合自己这些年在前端安全，特别是富文本编辑器安全上的踩坑经验，来拆解一下基于RoosterJS时，我们该如何系统地防范XSS攻击，并实施有效的内容净化策略。无论你是刚刚接触RoosterJS，还是已经用它开发了复杂编辑器，这里面的思路和实操细节，都值得你花时间琢磨。

2. 核心威胁解析：富文本编辑器中的XSS攻击是如何发生的？

在深入RoosterJS的具体实践之前，我们必须先搞清楚敌人是谁，以及它如何进攻。XSS（跨站脚本攻击）的核心，简单说就是“让不该执行的代码被执行了”。在富文本编辑器的场景下，这个风险被急剧放大。

2.1 富文本编辑器的独特风险点

普通表单输入，我们可能只需要对用户输入的纯文本进行HTML编码（比如把<变成<）就能基本防范。但富文本编辑器不同，它的核心功能就是让用户输入并应用HTML样式（如加粗、斜体、插入链接、图片）。这意味着，我们必须允许一部分HTML标签和属性存在，而不能一刀切地全部编码，否则编辑器就失去了“富文本”的意义。

这就带来了一个根本矛盾：我们需要区分“善意的格式化HTML”和“恶意的攻击脚本”。攻击者会利用这个矛盾，尝试注入恶意代码。常见的攻击向量包括：

1. 通过标签属性注入：比如一个看起来无害的图片标签<img src="x" onerror="stealCookie()">。src属性加载失败，就会触发onerror事件，执行其中的JavaScript。
2. 利用不规范的标签闭合：输入类似<script>alert(‘xss’)</script>是最低级的，现代浏览器和编辑器大多能过滤。但高级攻击会利用解析差异，比如<img src=xonerror=alert(1)>，这里利用未闭合的引号和空格，绕过简单的正则匹配。
3. SVG向量：SVG本质是XML，它可以内嵌<script>标签。用户如果直接粘贴或上传一个恶意SVG文件，并被当作图片渲染，就可能触发攻击。
4. 样式表注入：CSS中的expression()属性（旧版IE）或url(javascript:...)也可能成为攻击载体。
5. 通过数据属性或自定义属性隐藏Payload：攻击者可能将恶意代码藏在>import * as roosterjs from 'roosterjs'; import DOMPurify from 'dompurify'; // 1. 创建编辑器前，定义净化函数 const sanitizeConfig = { ALLOWED_TAGS: ['p', 'b', 'i', 'u', 'em', 'strong', 'a', 'ul', 'ol', 'li', 'br', 'img', 'h1', 'h2', 'h3'], ALLOWED_ATTR: ['href', 'target', 'src', 'alt', 'title', 'class'], // 对于<a>标签的href，确保只能是http/https/mailto，防止javascript:协议 ALLOWED_URI_REGEXP: /^(?:(?:(?:f|ht)tps?|mailto):|[^a-z]|[a-z+.\-]+(?:[^a-z+.\-:]|$))/i }; function sanitizeHTML(dirtyHtml) { return DOMPurify.sanitize(dirtyHtml, sanitizeConfig); } // 2. 设置内容时净化 const initialContent = fetchContentFromServer(); // 假设从服务器获取 editor.setContent(sanitizeHTML(initialContent)); // 3. 获取内容时净化（用于保存） function getSanitizedContent() { const rawContent = editor.getContent(); return sanitizeHTML(rawContent); }

   配置DOMPurify的策略：上面的sanitizeConfig是关键。你需要根据业务需求，精确定义ALLOWED_TAGS（允许的标签）和ALLOWED_ATTR（允许的属性）。原则是：最小化权限。只开放业务必须的标签和属性。例如，如果你不需要用户设置字体，就不要允许<font>标签和style属性。

   3.2 第二层：输出编码（Output Encoding）

   “输出编码”是防御XSS的黄金法则。它的核心思想是：将数据与其所在的上下文区分开。在哪个上下文输出，就用哪种编码方式。

   在RoosterJS的场景中，输出主要发生在：

   • 将编辑器内容（HTML）插入到页面DOM中。
   • 将内容中的某些属性（如链接的href、图片的src）动态设置到JavaScript中。

   对于直接插入HTML：如果你使用editor.getContent()获取HTML，然后通过innerHTML或类似方式插入到另一个DOM元素中，你已经在使用“HTML上下文”。此时，如果内容已经过DOMPurify净化，风险较低。但更安全的做法是，即使净化过，也考虑使用安全的API插入，例如：

   // 相对安全：净化后的HTML通过innerHTML插入 const cleanHtml = getSanitizedContent(); document.getElementById('preview').innerHTML = cleanHtml; // 替代方案：使用textContent避免HTML解析（但会失去格式） // document.getElementById('preview').textContent = cleanHtml; // 这会显示HTML源码，不是我们想要的

   实际上，经过严格净化的HTML使用innerHTML是业界通用做法。关键在于净化是否可靠。

   对于动态设置属性（进入HTML属性上下文）：假设你需要从编辑内容中提取所有链接并单独处理：

   // 危险！直接拼接字符串构造属性值 const userHref = extractHrefFromContent(); // 可能包含 javascript:alert(1) someLinkElement.setAttribute('href', userHref); // 安全：对属性值进行HTML属性编码 import { encode } from 'he'; // 使用 'he' 这样的编码库 const safeHref = encode(userHref, { useNamedReferences: true }); // 将 &, ", ', <, > 等编码 someLinkElement.setAttribute('href', safeHref); // 或者，更针对性地，确保href是安全的URL协议 if (!userHref.startsWith('http://') && !userHref.startsWith('https://') && !userHref.startsWith('mailto:')) { userHref = 'javascript:void(0)'; // 或一个安全的默认值 }

   对于将内容数据放入JavaScript变量（进入JavaScript上下文）：这通常发生在你需要将编辑器内容以JSON形式传递给前端脚本时。

   // 危险！直接将未净化的HTML嵌入到JS字符串中 const userContent = editor.getContent(); const scriptContent = `var data = "${userContent}";`; // 如果userContent包含引号，会破坏字符串结构，导致代码注入 // 安全：使用JSON.stringify进行编码 const userContent = editor.getContent(); const safeData = JSON.stringify(userContent); // 这会正确处理引号、换行符等 // 然后在你的脚本模板中 const scriptContent = `var data = ${safeData};`;

   RoosterJS本身不直接涉及这部分，但作为开发者，你必须意识到，从编辑器获取的内容如果要在JavaScript环境中流动，必须经过正确的编码。

   3.3 第三层：内容安全策略（Content Security Policy, CSP）

   CSP是一个由浏览器提供的、强大的深度防御安全层。它通过HTTP头告诉浏览器，哪些外部资源可以被加载和执行（如脚本、样式、图片、字体等），从而极大地限制了XSS攻击成功后的影响范围。

   对于RoosterJS编辑器，一个强化的CSP策略可能如下：

   Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self'

   让我们拆解这个策略对编辑器的意义：

   • script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’: 这可能是最矛盾的一点。富文本编辑器（包括RoosterJS）的很多功能依赖内联脚本和eval（例如处理粘贴内容、执行格式化命令）。为了编辑器正常工作，我们可能不得不暂时允许‘unsafe-inline’和‘unsafe-eval’。这是CSP在富文本场景下的一个主要挑战。 mitigation（缓解措施）是尽量将编辑器功能隔离到一个独立的iframe中，并为该iframe设置一个更宽松但独立的CSP策略，与主应用隔离。
   • img-src ‘self’ data: https:: 允许加载来自本站、data URL和HTTPS协议的图片。这覆盖了用户粘贴网络图片和base64图片的场景。
   • 其他指令如style-src也允许了‘unsafe-inline’，因为用户应用的样式很可能是内联的。

   实施建议：

   1. 从报告模式开始：部署CSP时，先使用Content-Security-Policy-Report-Only头，观察策略是否会阻断编辑器的正常功能。浏览器会将违规行为报告到你指定的端点。
   2. 逐步收紧：根据报告，逐步调整策略。尝试用哈希（hash）或随机数（nonce）来替代‘unsafe-inline’，但这对动态生成的编辑器代码可能不现实。
   3. 考虑iframe沙箱：将RoosterJS编辑器放置在一个具有独立源（origin）或使用sandbox属性的iframe中。这样，即使编辑器被XSS攻破，攻击者也很难访问父页面的Cookie或DOM。这是将风险隔离的非常有效的手段。

   注意事项：CSP不是万能的，它不能防止攻击者将恶意内容作为“数据”存入你的数据库（因为CSP管的是资源加载，不是数据内容）。它主要防御的是“注入的脚本被加载和执行”这一步。因此，CSP必须与内容净化结合使用。

   4. 实操过程：构建一个安全的RoosterJS编辑器实例

   理论说再多，不如动手搭一个。下面我将一步步展示如何初始化一个RoosterJS编辑器，并集成上述安全措施。

   4.1 环境准备与基础配置

   首先，安装核心依赖：

   npm install roosterjs dompurify # 如果需要编码，也可以安装 'he' 库 npm install he

   创建一个基础的编辑器组件SecureRoosterEditor.jsx（以React为例，原理通用）：

   import React, { useRef, useEffect, useState } from 'react'; import * as roosterjs from 'roosterjs'; import DOMPurify from 'dompurify'; // 1. 定义严格的内容净化策略 const getSanitizeConfig = (allowImages = true) => { const baseConfig = { ALLOWED_TAGS: [ 'p', 'br', 'b', 'strong', 'i', 'em', 'u', 's', 'strike', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'a', 'blockquote', 'code', 'pre', 'hr', 'sub', 'sup' ], ALLOWED_ATTR: ['href', 'target', 'title', 'class'], // 强制所有链接在新窗口打开，并确保协议安全 (可选，根据业务调整) ADD_ATTR: ['target'], ADD_TAGS: [], // 自定义处理函数，对链接进行额外安全检查 SAFE_FOR_JQUERY: false, SAFE_FOR_TEMPLATES: false, WHOLE_DOCUMENT: false, ALLOW_DATA_ATTR: false // 非常重要！禁止data-*属性，防止隐藏payload }; // 动态允许图片 if (allowImages) { baseConfig.ALLOWED_TAGS.push('img'); baseConfig.ALLOWED_ATTR.push('src', 'alt', 'title', 'width', 'height'); // 限制图片src协议 baseConfig.ALLOWED_URI_REGEXP = /^(?:(?:https?|ftp):|data:image\/[^;]+;base64,|[#a-z][a-z0-9+.-]*:?)/i; } // 对链接href进行严格过滤 baseConfig.ALLOWED_URI_REGEXP = baseConfig.ALLOWED_URI_REGEXP || /^(?:(?:https?|ftp|mailto):|[#a-z][a-z0-9+.-]*:?)/i; return baseConfig; }; const sanitizeHTML = (dirty, allowImages) => { const config = getSanitizeConfig(allowImages); return DOMPurify.sanitize(dirty, config); }; function SecureRoosterEditor({ initialValue, onContentChange, allowImages = true }) { const editorDivRef = useRef(null); const editorRef = useRef(null); const [isReady, setIsReady] = useState(false); // 2. 初始化编辑器 useEffect(() => { if (!editorDivRef.current || editorRef.current) return; // 对初始值进行净化 const sanitizedInitialValue = sanitizeHTML(initialValue || '', allowImages); // 创建RoosterJS编辑器实例 const editor = roosterjs.createEditor(editorDivRef.current, { // 可以在这里配置默认插件，例如粘贴处理插件对安全至关重要 plugins: [ // 粘贴时自动清理内容的插件是安全的关键！ // RoosterJS 提供了 `Paste` 插件，它会尝试在粘贴时进行清理。 // 我们可以进一步自定义其行为。 new roosterjs.Paste({ // 自定义粘贴处理器 onPaste: (event, data) => { // data.html 是粘贴的原始HTML // 我们可以在这里进行额外的净化 if (data.html) { data.html = sanitizeHTML(data.html, allowImages); } // 返回 false 表示不阻止默认的粘贴处理 return false; } }), // 其他功能插件... ], // 其他编辑器选项... initialContent: sanitizedInitialValue, }); editorRef.current = editor; setIsReady(true); // 监听内容变化，在获取内容时可以考虑二次净化（根据性能权衡） const disposeContentChanged = roosterjs.addEditorReadyListener(editor, () => { const dispose = roosterjs.addEventListener(editor, roosterjs.KnownEventType.ContentChanged, () => { if (onContentChange) { // 注意：这里为了实时性，可能没有进行净化。净化通常在保存时进行。 // 如果对实时性要求高且担心性能，可以在这里进行轻度净化或标记脏数据。 const currentContent = editor.getContent(); onContentChange(currentContent); } }); return dispose; }); return () => { if (editorRef.current) { editorRef.current.dispose(); editorRef.current = null; } if (disposeContentChanged) { disposeContentChanged(); } }; }, [initialValue, allowImages, onContentChange]); // 3. 提供一个安全的“获取内容”方法给父组件 const getSanitizedContent = () => { if (!editorRef.current) return ''; const raw = editorRef.current.getContent(); return sanitizeHTML(raw, allowImages); }; // 暴露方法给父组件（通过ref） useEffect(() => { if (isReady) { // 假设父组件通过ref调用 getSanitizedContent // 这里需要根据你的组件间通信方式调整 } }, [isReady]); return <div ref={editorDivRef} style={{ height: '400px', border: '1px solid #ccc' }} />; } export default SecureRoosterEditor;

   4.2 关键安全插件与自定义处理

   上面的代码中，我们重点集成了Paste插件并自定义了onPaste处理器。粘贴是富文本编辑器最大的XSS风险来源之一，因为用户可能从任何网页（包括恶意网页）复制内容。

   更深入的自定义净化： DOMPurify的配置可能还不够细。例如，我们可能想禁止某些特定的CSS样式（如position: fixed; top: -9999px;这种用于钓鱼的样式），或者对href和src进行更严格的URL验证。我们可以扩展净化过程：

   function advancedSanitize(dirtyHtml, allowImages) { let clean = DOMPurify.sanitize(dirtyHtml, getSanitizeConfig(allowImages)); // 后处理：使用DOM API进行更精细的控制 const tempDiv = document.createElement('div'); tempDiv.innerHTML = clean; // 1. 遍历所有<a>标签，验证并清理href const links = tempDiv.querySelectorAll('a[href]'); links.forEach(link => { const href = link.getAttribute('href'); if (href && !isSafeUrl(href)) { link.removeAttribute('href'); link.setAttribute('rel', 'nofollow noopener noreferrer'); // 添加安全属性 // 或者直接移除这个链接，只保留文本 // const text = document.createTextNode(link.textContent); // link.parentNode.replaceChild(text, link); } else { // 强制添加安全属性，防止 window.opener 攻击 link.setAttribute('target', '_blank'); link.setAttribute('rel', 'noopener noreferrer'); } }); // 2. 遍历所有元素，移除危险的样式属性 const allElements = tempDiv.querySelectorAll('*[style]'); allElements.forEach(el => { const style = el.getAttribute('style'); // 简单的危险样式过滤（实际应用需要更全面的列表） const dangerousPatterns = [/position\s*:\s*fixed/i, /z-index\s*:\s*9999/i]; let isDangerous = dangerousPatterns.some(pattern => pattern.test(style)); if (isDangerous) { el.removeAttribute('style'); } }); // 3. 移除所有事件处理器属性（如 onclick, onmouseover） // DOMPurify默认会移除，但这里可以再加一道保险 const eventAttributes = /^on\w+/i; allElements.forEach(el => { Array.from(el.attributes).forEach(attr => { if (eventAttributes.test(attr.name)) { el.removeAttribute(attr.name); } }); }); return tempDiv.innerHTML; } function isSafeUrl(url) { try { const parsed = new URL(url, window.location.href); // 使用当前页面地址作为基准 const allowedProtocols = ['http:', 'https:', 'mailto:', 'tel:', 'ftp:']; if (!allowedProtocols.includes(parsed.protocol)) { return false; } // 还可以检查域名是否在白名单内等 return true; } catch (e) { // 如果不是合法URL，则不安全 return false; } }

   然后将advancedSanitize函数替换掉简单的DOMPurify.sanitize调用。注意，这种DOM操作有一定性能开销，对于实时性要求极高的编辑场景（如每次按键都净化），需要谨慎评估或进行优化（如防抖处理）。

   4.3 服务器端加固：最后的防线

   前端的所有安全措施都可能被绕过（例如用户直接调用API发送恶意数据）。因此，服务器端必须进行完全独立的、不依赖于前端的验证和净化。

   策略：

   1. Schema验证：首先，对接收到的数据结构进行验证（例如，确保内容是字符串，长度在合理范围内）。
   2. 服务器端HTML净化：使用后端的HTML净化库。绝对不要信任前端DOMPurify处理过的数据。
      • Node.js: 可以使用jsdom配合DOMPurify在服务端运行，或者使用专门的库如sanitize-html。
      • Python (Django): Django模板有自动转义，但对于富文本，可以使用bleach库。
      • Java: 使用Jsoup库。
      • .NET: 使用HtmlSanitizer库。

   一个Node.js（使用Express）的服务器端净化示例：

   const express = require('express'); const createDOMPurify = require('dompurify'); const { JSDOM } = require('jsdom'); const app = express(); app.use(express.json()); const window = new JSDOM('').window; const DOMPurify = createDOMPurify(window); // 使用与前端类似但可能更严格的配置 const serverSanitizeConfig = { ALLOWED_TAGS: ['p', 'b', 'i', 'a', 'ul', 'ol', 'li', 'br', 'img'], ALLOWED_ATTR: ['href', 'target', 'src', 'alt', 'title'], ALLOWED_URI_REGEXP: /^(?:(?:https?|ftp):|data:image\/[^;]+;base64,)/i, FORBID_ATTR: ['style', 'onerror', 'onload'] // 明确禁止某些属性 }; app.post('/api/save-content', (req, res) => { const { rawContent } = req.body; // 1. 基础验证 if (typeof rawContent !== 'string' || rawContent.length > 100000) { return res.status(400).json({ error: 'Invalid content' }); } // 2. 服务器端净化（使用独立于前端的配置和库） const sanitizedContent = DOMPurify.sanitize(rawContent, serverSanitizeConfig); // 3. （可选）进一步处理，如将相对URL转换为绝对URL，或过滤特定关键词 // const furtherProcessed = processContent(sanitizedContent); // 4. 存储 sanitizedContent 到数据库 // db.save(sanitizedContent); res.json({ success: true, message: 'Content saved (and sanitized server-side).' }); });

   关键点：服务器端的净化配置可以比客户端更严格。因为服务器端不需要考虑用户体验（如某些复杂的样式），它的唯一目标就是安全。甚至可以完全剥离所有HTML标签，只保留纯文本（如果业务允许），这是最安全的做法。

   5. 常见问题与排查技巧实录

   在实际开发和维护中，你会遇到各种各样的问题。下面是我总结的一些典型场景和解决方案。

   5.1 问题：粘贴内容后格式丢失严重（尤其是从Word、网页粘贴）

   原因：DOMPurify或你的净化配置过于严格，移除了许多用于样式的标签（如<span>,<font>,style属性）和类名。排查：

   1. 检查DOMPurify的ALLOWED_TAGS和ALLOWED_ATTR配置。是否包含了必要的标签如span,div？是否允许了class和style属性？（允许style属性风险较高，需谨慎）。
   2. 检查RoosterJS的粘贴插件。RoosterJS的Paste插件内部有一个转换过程，会尝试将来自Word等源的复杂HTML转换为更简洁、兼容的HTML。这个转换过程本身可能会丢失信息。可以监听粘贴事件，查看data.html在处理前后的变化。解决：
   • 放宽净化策略：如果业务允许一定的富样式，可以谨慎地添加更多标签和属性到白名单。对于style，可以尝试只允许某些安全的CSS属性（如color,font-weight），这需要更复杂的解析，DOMPurify本身不支持，需要后处理。
   • 使用更智能的粘贴处理：考虑使用专门的粘贴富文本清理库，如ProseMirror的transform模块或自定义解析器，在保留基本格式（段落、列表、链接、图片）的同时，剥离脚本和危险样式。
   • 提供“纯文本粘贴”选项：给用户一个选择，让他们可以粘贴为纯文本，这是最安全的方式。

   5.2 问题：净化后，编辑器内显示异常（如出现奇怪的字符<）

   原因：这是双重编码的典型表现。可能的情况是：

   1. 服务器端返回的数据已经是HTML实体编码的（例如，存储的是<script>）。
   2. 前端在设置到编辑器（setContent）之前，又进行了一次净化/编码。DOMPurify或浏览器会将<当作文本，但为了安全，可能又将其编码为<，或者直接将其作为文本节点插入，导致编辑器内显示的是源码而非渲染后的符号<。排查：
   • 在浏览器开发者工具中，检查网络请求，看服务器返回的原始数据是什么格式。
   • 在setContent前后，用console.log打印内容，观察变化。解决：
   • 统一数据格式：约定在整个系统中，数据库存储和API传输的都是净化后的、未编码的HTML。也就是说，<就应该存为<字符，而不是<。编码（escape）只发生在将数据输出到不同上下文时（如输出到HTML属性、JavaScript字符串）。
   • 净化前确保数据是原始HTML：如果服务器返回的是编码后的实体，前端需要先解码（例如使用he.decode()），然后再进行净化，最后再设置到编辑器。

   5.3 问题：图片上传功能与安全策略冲突

   原因：你允许了img标签和src属性，但src可能是data:image/...或任意URL。攻击者可能注入一个非常大的data URL导致页面卡死，或者链接到一个恶意跟踪URL。解决：

   • 限制src协议：在DOMPurify配置中，使用ALLOWED_URI_REGEXP严格限制src和href的协议。通常只允许http:,https:,data:image/*(用于base64预览)，以及可能的相对路径。
   • 处理图片上传：不要允许用户直接使用任意网络图片URL。最佳实践是提供图片上传功能：
     1. 用户选择图片文件。
     2. 前端将图片上传到你的服务器（或安全的云存储如AWS S3、Cloudinary）。
     3. 服务器端对图片文件进行验证（文件头、MIME类型、大小、甚至内容扫描）。
     4. 服务器返回一个由你控制的、安全的URL（如https://your-cdn.com/xxx.jpg）。
     5. 编辑器插入这个安全的图片URL。这样，你完全掌控了图片的来源。
   • 使用代理服务：如果必须支持外部图片URL，可以考虑通过你自己的服务器代理下载并检查图片，然后再提供给前端。这样可以避免用户浏览器直接连接到潜在恶意的第三方服务器。

   5.4 问题：CSP策略导致编辑器功能（如工具栏按钮）失效

   原因：编辑器的UI组件（特别是工具栏）可能需要加载内联脚本或样式，或者使用eval动态执行代码，这被严格的CSP策略阻止了。排查：打开浏览器开发者工具的Console和Network面板，查看CSP违规报告。解决：

   • 为编辑器资源生成Nonce或Hash：如果编辑器构建出的脚本和样式是固定的，可以为它们计算哈希值并添加到CSP指令中（如script-src ‘sha256-xxx’）。但这对于复杂的、动态生成的编辑器代码可能很困难。
   • 隔离编辑器：将编辑器放置在一个单独的<iframe>中，并为这个iframe设置一个专门放宽的CSP策略（例如包含‘unsafe-inline’）。主应用的CSP保持严格。这样，即使iframe内的编辑器被攻破，攻击面也被限制在iframe内。
   • 调整CSP策略：如果以上都不可行，可能需要在script-src和style-src中为编辑器所在的特定路径或域名添加例外。但这会降低整体安全性，应作为最后手段。

   5.5 安全审计清单

   在项目上线前或定期进行安全检查时，可以对照这个清单：

   1. [ ]输入净化：是否在所有用户内容入口（编辑器初始化、粘贴、API接收）使用了可靠的HTML净化库（如DOMPurify）？
   2. [ ]净化策略：净化白名单（标签、属性）是否遵循了最小权限原则？是否禁用了script,style(或严格过滤),iframe,object,embed,form,input等高风险标签？是否禁用了on*事件处理器属性？
   3. [ ]URL安全：是否对href和src属性值进行了协议白名单验证（仅允许http,https,mailto, 等）？是否处理了javascript:和data:协议的风险？
   4. [ ]输出编码：在将编辑器内容插入非编辑区域（如文章展示页）时，是否确保了上下文安全？如果作为数据插入JavaScript，是否使用了JSON.stringify？
   5. [ ]服务器端净化：后端API是否对接收到的HTML内容进行了独立的、不依赖于前端的净化？
   6. [ ]CSP策略：是否部署了Content-Security-Policy头？是否在报告模式下测试了所有编辑器功能？是否考虑了iframe隔离方案？
   7. [ ]依赖管理：是否定期更新RoosterJS、DOMPurify等依赖，以获取安全补丁？
   8. [ ]上传处理：图片/文件上传功能是否经过服务器端验证和重命名？用户是否能直接插入任意网络图片？
   9. [ ]剪贴板监控：是否在粘贴时进行了额外的清理（利用RoosterJS Paste插件）？
   10. [ ]错误处理：前端净化或后端验证失败时，是否有清晰的错误处理和用户提示，而不是暴露原始错误信息？

   最后，我个人最深刻的体会是：安全没有银弹。RoosterJS是一个优秀的框架，但它不会替你完成所有安全工作。防御XSS是一场持久战，需要你将“不信任用户输入”的原则贯彻到每一个数据流动的环节，并建立起输入净化、输出编码、CSP、服务器端验证的纵深防御体系。每次添加新的编辑器功能（比如插入视频、自定义模板）时，都要重新评估其安全影响。保持警惕，定期审计，才能让你的富文本应用在提供强大功能的同时，屹立于安全之地。