1. 项目概述为什么Vue3项目必须关注XSS防护在Vue3项目中处理用户输入时一个看似简单的需求——过滤特殊字符背后往往关联着Web安全中最常见也最危险的漏洞之一跨站脚本攻击。很多开发者尤其是刚接触Vue3生态的朋友可能会觉得框架本身已经提供了v-html的警告或者认为现代前端框架的响应式系统能自动规避这些问题。但实际情况是XSS的防御是一个多层次、需要主动干预的工程。无论是用户评论、富文本编辑器内容、还是从第三方接口获取并需要动态渲染的数据只要存在将字符串当作HTML解析的机会攻击者就可能注入恶意脚本窃取用户Cookie、发起非法请求甚至控制用户会话。我接手过不少从Vue2迁移到Vue3的项目发现一个普遍现象大家热衷于使用script setup、组合式API、Vite这些新特性提升开发体验但在安全防护的实践上往往还停留在“用正则表达式过滤一下”的初级阶段。正则表达式对付简单的script标签或许有效但面对HTML实体编码、事件处理器属性、javascript:伪协议、CSS表达式等五花八门的攻击向量就显得力不从心极易产生遗漏。这就是为什么我们需要一个专门、健壮的解决方案。DOMPurify正是为此而生。它是一个仅针对DOM的、超快速、超宽容的XSS净化工具。它的核心逻辑不是用黑名单去猜测哪些是“坏”的而是采用白名单机制只允许已知安全的HTML元素和属性通过其他一律清除或转义。在Vue3的上下文中集成DOMPurify意味着我们可以在数据流入视图层之前筑起一道可靠的防线确保动态内容的渲染安全无虞。这不仅是功能实现更是项目上线前必须通过的安全审计项。2. 核心思路与方案选型为什么是DOMPurify面对XSS防护开发者通常有几个选择手动转义、使用内置API、引入专用库。我们需要逐一分析才能理解为什么DOMPurify在Vue3场景下是最佳实践。2.1 常见方案对比与陷阱方案一手动转义或简单正则过滤这是最原始的方法。例如写一个函数将、、、、等字符替换为对应的HTML实体lt;gt;等。或者写一个正则表达式去移除script标签。为什么不行XSS的攻击面极其广泛。除了scriptalert(1)/script这种明显的形式还有事件处理器img srcx onerroralert(1)HTML属性a hrefjavascript:alert(1)点击/aCSS注入div stylebackground:url(javascript:alert(1))SVG/数学ML这些标记语言内也可能包含可执行脚本。编码绕过攻击者可能使用十进制、十六进制HTML实体或Unicode来混淆过滤逻辑。 手动实现一个能覆盖所有情况的过滤器复杂度极高且极易因考虑不周而产生漏洞。安全领域有句老话“不要自己发明加密算法”同样也不要自己发明XSS过滤器。方案二依赖Vue的文本插值与v-htmlVue的模板语法{{ }}会自动对数据进行HTML转义这是安全的。问题出在v-html指令上它是Vue提供的、用于输出原始HTML的“逃生舱”。Vue会在控制台给出警告“注意在网站上动态渲染任意HTML非常危险因为它很容易导致XSS攻击。仅在可信内容上使用v-html永远不要用于用户提交的内容。”关键点Vue只负责警告不负责净化。它把安全的责任完全交给了开发者。如果你确信内容安全比如来自完全受控的后端且已净化可以使用v-html。但对于任何来自用户或不可信源的内容直接使用v-html等于开门揖盗。方案三使用浏览器内置的textContent或创建文本节点如果我们只是想安全地显示一段文本完全避免HTML解析那么textContent属性是完美的。它不会将字符串当作HTML解析而是原样输出。但这无法满足“需要渲染部分安全HTML”的需求比如用户评论里包含加粗、斜体、链接等合法格式。2.2 DOMPurify的优势解析经过对比DOMPurify的优势就非常明显了白名单机制这是其安全性的基石。它维护了一个庞大的、经过安全评估的“允许名单”包括安全的标签如b,i,a,span、安全的属性如href,title,class且会对href的值进行协议检查禁止javascript:。不在名单上的东西默认会被丢弃。这种“默认拒绝”的策略比“默认允许”要安全得多。配置灵活你可以通过配置对象轻松地扩展或缩减这个白名单。例如你的应用只需要b和i标签你可以将其他所有标签禁用或者你需要支持iframe但必须限制其src为特定的域名。处理复杂它能智能处理嵌套的恶意代码、多种编码方式的攻击载荷、以及各种边缘情况其测试用例覆盖了成千上万种已知的XSS攻击向量。与DOM协同它直接在DOM环境下工作解析、净化、返回一个安全的HTML字符串或DOM节点与Vue的v-html指令可以无缝衔接。轻量且高效库的体积小净化速度快对应用性能影响微乎其微。因此在Vue3项目中对于需要渲染富文本或不可信HTML的场景标准做法是使用DOMPurify对原始字符串进行净化然后将净化后的安全字符串通过v-html指令进行渲染。这样既满足了功能需求又恪守了安全底线。3. 在Vue3项目中集成与配置DOMPurify理论清晰了接下来我们一步步在Vue3项目中落地。我将以最常见的Vite Vue3 TypeScript项目为例进行说明。3.1 安装依赖首先通过npm或yarn安装DOMPurify及其对应的TypeScript类型定义文件。npm install dompurify npm install -D types/dompurify # 或 yarn add dompurify yarn add -D types/dompurify3.2 创建净化工具函数/Composable为了在项目中复用我们通常会创建一个工具函数或一个Vue3组合式函数。我更喜欢将其封装为composable因为它更符合Vue3的组合式逻辑并且可以方便地与其他组合式函数如获取数据的逻辑结合。在src/composables目录下如果没有请创建新建一个文件useDomPurify.ts// src/composables/useDomPurify.ts import DOMPurify from dompurify; import { Ref, ref, watch } from vue; // 定义配置类型这里只列举常用项可根据DOMPurify文档扩展 export interface PurifyConfig { ALLOWED_TAGS?: string[]; ALLOWED_ATTR?: string[]; FORBID_ATTR?: string[]; ALLOW_DATA_ATTR?: boolean; // 更多配置见 https://github.com/cure53/DOMPurify } /** * 创建一个用于净化HTML的Vue3组合式函数 * param initialConfig DOMPurify的初始配置 * returns 包含净化函数和动态配置引用的对象 */ export function useDomPurify(initialConfig: PurifyConfig {}) { // 使用ref来管理配置使其具有响应性如果需要动态修改 const config refPurifyConfig({ // 默认配置允许一些基本的、安全的标签和属性 ALLOWED_TAGS: [b, i, em, strong, a, p, br, ul, ol, li, span, div], ALLOWED_ATTR: [href, title, target, class, style], // 禁止一些风险较高的属性如onerror, onclick等 FORBID_ATTR: [onerror, onload, onclick, onmouseover], // 默认不允许自定义data-*属性除非明确需要 ALLOW_DATA_ATTR: false, ...initialConfig, // 用户传入的配置可以覆盖默认值 }); /** * 核心净化函数 * param dirty 待净化的原始HTML字符串 * param customConfig 可选的本次净化专用配置会与默认配置合并 * returns 净化后的安全HTML字符串 */ const sanitize (dirty: string, customConfig?: PurifyConfig): string { if (!dirty) return ; // 合并配置本次自定义配置 实例默认配置 const finalConfig { ...config.value, ...customConfig }; try { // 调用DOMPurify.sanitize方法 return DOMPurify.sanitize(dirty, finalConfig); } catch (error) { console.error(DOMPurify sanitization error:, error); // 净化出错时返回空字符串是最安全的选择也可以选择转义后返回 return ; } }; /** * 创建一个响应式的净化结果 * 适用于需要监听源字符串变化并自动净化的场景 * param source 一个响应式引用(Ref)包含待净化的字符串 * param customConfig 净化配置 * returns 一个响应式引用其值为净化后的安全字符串 */ const useSanitized (source: Refstring, customConfig?: PurifyConfig) { const sanitized ref(); watch( source, (newVal) { sanitized.value sanitize(newVal, customConfig); }, { immediate: true } // 立即执行一次 ); return sanitized; }; return { sanitize, useSanitized, config, // 暴露配置引用允许组件动态修改谨慎使用 }; }3.3 在组件中使用现在我们可以在任何Vue组件中引入并使用这个composable了。场景一直接净化并渲染!-- src/components/CommentItem.vue -- template div classcomment !-- 使用v-html渲染净化后的内容 -- div classcontent v-htmlsafeContent/div /div /template script setup langts import { computed } from vue; import { useDomPurify } from /composables/useDomPurify; const props defineProps{ rawContent: string; // 从API获取的原始评论内容 }(); const { sanitize } useDomPurify(); // 使用计算属性当rawContent变化时自动重新净化 const safeContent computed(() sanitize(props.rawContent)); /script场景二处理富文本编辑器内容假设我们有一个富文本编辑器如TinyMCE、Quill用户提交的内容是完整的HTML。我们可能希望允许更多格式但同时要严格限制。!-- src/components/RichTextViewer.vue -- template div classrich-text-viewer v-htmlsanitizedHtml/div /template script setup langts import { ref, watch } from vue; import { useDomPurify } from /composables/useDomPurify; const props defineProps{ html: string; }(); const { sanitize, useSanitized } useDomPurify({ // 针对富文本放宽白名单但增加更严格的属性控制 ALLOWED_TAGS: [ h1, h2, h3, p, br, b, i, strong, em, u, s, blockquote, code, pre, ul, ol, li, a, img, span, div ], ALLOWED_ATTR: [href, title, target, class, style, src, alt, width, height], // 强制所有链接在新窗口打开并添加relnoopener noreferrer防止钓鱼 // 注意ADD_ATTR需要DOMPurify的特定配置支持这里演示思路 }); // 或者使用useSanitized const htmlRef ref(props.html); const sanitizedHtml useSanitized(htmlRef); // 如果html prop变化 watch(() props.html, (newVal) { htmlRef.value newVal; }); /script注意对于target_blank的链接强烈建议通过DOMPurify的ADD_ATTR配置或净化后手动添加relnoopener noreferrer属性以防止window.openerAPI带来的安全风险。这虽然不属于XSS范畴但也是重要的安全最佳实践。4. 高级配置与实战技巧DOMPurify的强大在于其丰富的配置。下面分享几个实战中高频使用的配置技巧和注意事项。4.1 自定义白名单与黑名单扩展白名单如果你的应用需要支持table、iframe需极度谨慎等标签只需将其加入ALLOWED_TAGS数组。缩减白名单为了极致安全你可以只允许最基本的标签。例如一个只显示加粗、斜体和链接的评论系统const strictConfig { ALLOWED_TAGS: [b, strong, i, em, a], ALLOWED_ATTR: [href, title], };使用黑名单FORBID_TAGS和FORBID_ATTR可以明确禁止某些内容即使它们在白名单中。但优先使用白名单是更安全的心态。4.2 处理样式属性允许style属性存在风险因为CSS也可以执行脚本如expression(...)旧式IE攻击或background: url(javascript:...)。DOMPurify默认会对style属性值进行解析和过滤只允许安全的CSS属性。你可以通过ALLOWED_ATTR包含style但务必了解其风险。对于来自不可信源的HTML最好直接禁止style。4.3 净化SVGSVG本身是XML也可能包含脚本。DOMPurify默认支持净化SVG内容。确保你的配置没有意外地禁用相关功能。4.4 在Node.js环境使用DOMPurify需要DOM环境。在Vue3的SSR服务端渲染场景下Node.js中没有window对象。你需要创建一个模拟的DOM环境常用的工具是jsdom。npm install jsdom然后在你的服务端入口文件如server.js或SSR相关文件中import { JSDOM } from jsdom; import DOMPurify from dompurify; const window new JSDOM().window; const purify DOMPurify(window); // 现在可以使用purify.sanitize(...) const clean purify.sanitize(dirtyHtml);在你的通用工具函数中需要做环境判断// src/utils/sanitize.ts import DOMPurify from dompurify; let purify DOMPurify; if (typeof window undefined) { // 服务端环境 const { JSDOM } await import(jsdom); const dom new JSDOM(); purify DOMPurify(dom.window); } export const sanitize (dirty: string) purify.sanitize(dirty);4.5 性能考量与缓存对于高频更新的内容如实时聊天频繁调用sanitize可能成为性能瓶颈。虽然DOMPurify很快但仍需注意对于相同的内容可以考虑缓存净化结果。如果内容变化是追加式的如聊天记录可以只净化新增的部分。在Vue的computed属性中使用是合理的因为Vue会进行依赖追踪和缓存。5. 常见问题、排查技巧与安全边界即使使用了DOMPurify也并非一劳永逸。以下是我在实践中总结的常见坑点和排查清单。5.1 净化后样式丢失或布局错乱问题净化后的HTML渲染出来样式全无布局混乱。原因DOMPurify默认的白名单非常严格可能移除了你的HTML中含有的class、style或特定标签如div、span。排查检查净化前的原始HTML字符串。检查你传递给DOMPurify.sanitize的配置对象确认ALLOWED_TAGS和ALLOWED_ATTR是否包含了所需内容。在开发环境下可以临时将净化后的字符串console.log出来对比净化前后差异。解决根据业务需求适当扩展白名单配置。如果样式完全由上层CSS类控制确保class属性在ALLOWED_ATTR中。5.2 链接的target和rel属性处理不当问题净化后的链接点击后可能在本页打开导致用户离开你的应用或者存在target_blank的安全风险。解决如果你想强制所有外链在新窗口打开并添加安全属性可以在净化后使用DOM操作或字符串处理来批量修改。DOMPurify的RETURN_DOM或RETURN_DOM_FRAGMENT配置可以返回DOM节点方便操作。const clean DOMPurify.sanitize(dirty, { RETURN_DOM_FRAGMENT: true, ALLOWED_TAGS: [a], ALLOWED_ATTR: [href] }); clean.querySelectorAll(a).forEach(a { a.setAttribute(target, _blank); a.setAttribute(rel, noopener noreferrer); }); // 然后将DOM片段插入或转换为字符串更精细的控制如只对外部链接修改需要自己解析href的域名。5.3 与Vue的响应式系统结合时出现无限循环问题在watch或computed中调用净化函数如果净化函数内部修改了依赖的响应式变量可能导致无限更新。解决确保净化函数是纯函数不产生副作用。将待净化的数据作为参数传入而不是在函数内部读取响应式状态。使用我们上面封装的useSanitized可以很好地管理这种依赖关系。5.4 误以为净化能解决所有安全问题重要提醒DOMPurify解决的是HTML注入导致的XSS。它不能防止存储型XSS如果恶意脚本已经通过未净化的输入存入了数据库净化前端显示只是治标。净化必须在数据入库前进行至少要在后端做一次。前后端双重净化是黄金标准。基于DOM的XSS如果JavaScript代码直接使用innerHTML或eval()等操作未净化的数据DOMPurify也帮不上忙。需要避免不安全的DOM操作。其他Web漏洞如SQL注入、CSRF、文件上传漏洞等。5.5 配置错误导致规则被绕过问题自定义配置时错误地允许了危险标签或属性。案例为了支持“自定义表情”允许了img标签的onerror属性。原则遵循最小权限原则。只开放业务必需的功能。每次修改白名单都要问自己这个标签/属性是否绝对必要有没有更安全的替代方案5.6 测试你的净化策略不要相信“应该没问题”。建立测试用例单元测试为你的sanitize函数编写测试输入各种已知的XSS攻击向量断言输出是安全的或已被移除。使用在线XSS测试工具或Payload清单进行手动测试。考虑在代码审查中将安全配置的变更作为重点审查项。将DOMPurify集成到Vue3项目中更像是在数据流动的管道中安装了一个高效可靠的过滤器。它不能替代全面的安全开发意识但能为你的应用抵御绝大部分前端HTML注入攻击。记住安全是一个过程而不是一个产品。保持依赖库的更新关注安全社区动态定期审查你的安全配置才能让你的Vue3应用在享受开发效率的同时筑起坚固的安全防线。
Vue3项目XSS防护实战：DOMPurify集成与配置指南
发布时间：2026/6/24 7:02:17
1. 项目概述为什么Vue3项目必须关注XSS防护在Vue3项目中处理用户输入时一个看似简单的需求——过滤特殊字符背后往往关联着Web安全中最常见也最危险的漏洞之一跨站脚本攻击。很多开发者尤其是刚接触Vue3生态的朋友可能会觉得框架本身已经提供了v-html的警告或者认为现代前端框架的响应式系统能自动规避这些问题。但实际情况是XSS的防御是一个多层次、需要主动干预的工程。无论是用户评论、富文本编辑器内容、还是从第三方接口获取并需要动态渲染的数据只要存在将字符串当作HTML解析的机会攻击者就可能注入恶意脚本窃取用户Cookie、发起非法请求甚至控制用户会话。我接手过不少从Vue2迁移到Vue3的项目发现一个普遍现象大家热衷于使用script setup、组合式API、Vite这些新特性提升开发体验但在安全防护的实践上往往还停留在“用正则表达式过滤一下”的初级阶段。正则表达式对付简单的script标签或许有效但面对HTML实体编码、事件处理器属性、javascript:伪协议、CSS表达式等五花八门的攻击向量就显得力不从心极易产生遗漏。这就是为什么我们需要一个专门、健壮的解决方案。DOMPurify正是为此而生。它是一个仅针对DOM的、超快速、超宽容的XSS净化工具。它的核心逻辑不是用黑名单去猜测哪些是“坏”的而是采用白名单机制只允许已知安全的HTML元素和属性通过其他一律清除或转义。在Vue3的上下文中集成DOMPurify意味着我们可以在数据流入视图层之前筑起一道可靠的防线确保动态内容的渲染安全无虞。这不仅是功能实现更是项目上线前必须通过的安全审计项。2. 核心思路与方案选型为什么是DOMPurify面对XSS防护开发者通常有几个选择手动转义、使用内置API、引入专用库。我们需要逐一分析才能理解为什么DOMPurify在Vue3场景下是最佳实践。2.1 常见方案对比与陷阱方案一手动转义或简单正则过滤这是最原始的方法。例如写一个函数将、、、、等字符替换为对应的HTML实体lt;gt;等。或者写一个正则表达式去移除script标签。为什么不行XSS的攻击面极其广泛。除了scriptalert(1)/script这种明显的形式还有事件处理器img srcx onerroralert(1)HTML属性a hrefjavascript:alert(1)点击/aCSS注入div stylebackground:url(javascript:alert(1))SVG/数学ML这些标记语言内也可能包含可执行脚本。编码绕过攻击者可能使用十进制、十六进制HTML实体或Unicode来混淆过滤逻辑。 手动实现一个能覆盖所有情况的过滤器复杂度极高且极易因考虑不周而产生漏洞。安全领域有句老话“不要自己发明加密算法”同样也不要自己发明XSS过滤器。方案二依赖Vue的文本插值与v-htmlVue的模板语法{{ }}会自动对数据进行HTML转义这是安全的。问题出在v-html指令上它是Vue提供的、用于输出原始HTML的“逃生舱”。Vue会在控制台给出警告“注意在网站上动态渲染任意HTML非常危险因为它很容易导致XSS攻击。仅在可信内容上使用v-html永远不要用于用户提交的内容。”关键点Vue只负责警告不负责净化。它把安全的责任完全交给了开发者。如果你确信内容安全比如来自完全受控的后端且已净化可以使用v-html。但对于任何来自用户或不可信源的内容直接使用v-html等于开门揖盗。方案三使用浏览器内置的textContent或创建文本节点如果我们只是想安全地显示一段文本完全避免HTML解析那么textContent属性是完美的。它不会将字符串当作HTML解析而是原样输出。但这无法满足“需要渲染部分安全HTML”的需求比如用户评论里包含加粗、斜体、链接等合法格式。2.2 DOMPurify的优势解析经过对比DOMPurify的优势就非常明显了白名单机制这是其安全性的基石。它维护了一个庞大的、经过安全评估的“允许名单”包括安全的标签如b,i,a,span、安全的属性如href,title,class且会对href的值进行协议检查禁止javascript:。不在名单上的东西默认会被丢弃。这种“默认拒绝”的策略比“默认允许”要安全得多。配置灵活你可以通过配置对象轻松地扩展或缩减这个白名单。例如你的应用只需要b和i标签你可以将其他所有标签禁用或者你需要支持iframe但必须限制其src为特定的域名。处理复杂它能智能处理嵌套的恶意代码、多种编码方式的攻击载荷、以及各种边缘情况其测试用例覆盖了成千上万种已知的XSS攻击向量。与DOM协同它直接在DOM环境下工作解析、净化、返回一个安全的HTML字符串或DOM节点与Vue的v-html指令可以无缝衔接。轻量且高效库的体积小净化速度快对应用性能影响微乎其微。因此在Vue3项目中对于需要渲染富文本或不可信HTML的场景标准做法是使用DOMPurify对原始字符串进行净化然后将净化后的安全字符串通过v-html指令进行渲染。这样既满足了功能需求又恪守了安全底线。3. 在Vue3项目中集成与配置DOMPurify理论清晰了接下来我们一步步在Vue3项目中落地。我将以最常见的Vite Vue3 TypeScript项目为例进行说明。3.1 安装依赖首先通过npm或yarn安装DOMPurify及其对应的TypeScript类型定义文件。npm install dompurify npm install -D types/dompurify # 或 yarn add dompurify yarn add -D types/dompurify3.2 创建净化工具函数/Composable为了在项目中复用我们通常会创建一个工具函数或一个Vue3组合式函数。我更喜欢将其封装为composable因为它更符合Vue3的组合式逻辑并且可以方便地与其他组合式函数如获取数据的逻辑结合。在src/composables目录下如果没有请创建新建一个文件useDomPurify.ts// src/composables/useDomPurify.ts import DOMPurify from dompurify; import { Ref, ref, watch } from vue; // 定义配置类型这里只列举常用项可根据DOMPurify文档扩展 export interface PurifyConfig { ALLOWED_TAGS?: string[]; ALLOWED_ATTR?: string[]; FORBID_ATTR?: string[]; ALLOW_DATA_ATTR?: boolean; // 更多配置见 https://github.com/cure53/DOMPurify } /** * 创建一个用于净化HTML的Vue3组合式函数 * param initialConfig DOMPurify的初始配置 * returns 包含净化函数和动态配置引用的对象 */ export function useDomPurify(initialConfig: PurifyConfig {}) { // 使用ref来管理配置使其具有响应性如果需要动态修改 const config refPurifyConfig({ // 默认配置允许一些基本的、安全的标签和属性 ALLOWED_TAGS: [b, i, em, strong, a, p, br, ul, ol, li, span, div], ALLOWED_ATTR: [href, title, target, class, style], // 禁止一些风险较高的属性如onerror, onclick等 FORBID_ATTR: [onerror, onload, onclick, onmouseover], // 默认不允许自定义data-*属性除非明确需要 ALLOW_DATA_ATTR: false, ...initialConfig, // 用户传入的配置可以覆盖默认值 }); /** * 核心净化函数 * param dirty 待净化的原始HTML字符串 * param customConfig 可选的本次净化专用配置会与默认配置合并 * returns 净化后的安全HTML字符串 */ const sanitize (dirty: string, customConfig?: PurifyConfig): string { if (!dirty) return ; // 合并配置本次自定义配置 实例默认配置 const finalConfig { ...config.value, ...customConfig }; try { // 调用DOMPurify.sanitize方法 return DOMPurify.sanitize(dirty, finalConfig); } catch (error) { console.error(DOMPurify sanitization error:, error); // 净化出错时返回空字符串是最安全的选择也可以选择转义后返回 return ; } }; /** * 创建一个响应式的净化结果 * 适用于需要监听源字符串变化并自动净化的场景 * param source 一个响应式引用(Ref)包含待净化的字符串 * param customConfig 净化配置 * returns 一个响应式引用其值为净化后的安全字符串 */ const useSanitized (source: Refstring, customConfig?: PurifyConfig) { const sanitized ref(); watch( source, (newVal) { sanitized.value sanitize(newVal, customConfig); }, { immediate: true } // 立即执行一次 ); return sanitized; }; return { sanitize, useSanitized, config, // 暴露配置引用允许组件动态修改谨慎使用 }; }3.3 在组件中使用现在我们可以在任何Vue组件中引入并使用这个composable了。场景一直接净化并渲染!-- src/components/CommentItem.vue -- template div classcomment !-- 使用v-html渲染净化后的内容 -- div classcontent v-htmlsafeContent/div /div /template script setup langts import { computed } from vue; import { useDomPurify } from /composables/useDomPurify; const props defineProps{ rawContent: string; // 从API获取的原始评论内容 }(); const { sanitize } useDomPurify(); // 使用计算属性当rawContent变化时自动重新净化 const safeContent computed(() sanitize(props.rawContent)); /script场景二处理富文本编辑器内容假设我们有一个富文本编辑器如TinyMCE、Quill用户提交的内容是完整的HTML。我们可能希望允许更多格式但同时要严格限制。!-- src/components/RichTextViewer.vue -- template div classrich-text-viewer v-htmlsanitizedHtml/div /template script setup langts import { ref, watch } from vue; import { useDomPurify } from /composables/useDomPurify; const props defineProps{ html: string; }(); const { sanitize, useSanitized } useDomPurify({ // 针对富文本放宽白名单但增加更严格的属性控制 ALLOWED_TAGS: [ h1, h2, h3, p, br, b, i, strong, em, u, s, blockquote, code, pre, ul, ol, li, a, img, span, div ], ALLOWED_ATTR: [href, title, target, class, style, src, alt, width, height], // 强制所有链接在新窗口打开并添加relnoopener noreferrer防止钓鱼 // 注意ADD_ATTR需要DOMPurify的特定配置支持这里演示思路 }); // 或者使用useSanitized const htmlRef ref(props.html); const sanitizedHtml useSanitized(htmlRef); // 如果html prop变化 watch(() props.html, (newVal) { htmlRef.value newVal; }); /script注意对于target_blank的链接强烈建议通过DOMPurify的ADD_ATTR配置或净化后手动添加relnoopener noreferrer属性以防止window.openerAPI带来的安全风险。这虽然不属于XSS范畴但也是重要的安全最佳实践。4. 高级配置与实战技巧DOMPurify的强大在于其丰富的配置。下面分享几个实战中高频使用的配置技巧和注意事项。4.1 自定义白名单与黑名单扩展白名单如果你的应用需要支持table、iframe需极度谨慎等标签只需将其加入ALLOWED_TAGS数组。缩减白名单为了极致安全你可以只允许最基本的标签。例如一个只显示加粗、斜体和链接的评论系统const strictConfig { ALLOWED_TAGS: [b, strong, i, em, a], ALLOWED_ATTR: [href, title], };使用黑名单FORBID_TAGS和FORBID_ATTR可以明确禁止某些内容即使它们在白名单中。但优先使用白名单是更安全的心态。4.2 处理样式属性允许style属性存在风险因为CSS也可以执行脚本如expression(...)旧式IE攻击或background: url(javascript:...)。DOMPurify默认会对style属性值进行解析和过滤只允许安全的CSS属性。你可以通过ALLOWED_ATTR包含style但务必了解其风险。对于来自不可信源的HTML最好直接禁止style。4.3 净化SVGSVG本身是XML也可能包含脚本。DOMPurify默认支持净化SVG内容。确保你的配置没有意外地禁用相关功能。4.4 在Node.js环境使用DOMPurify需要DOM环境。在Vue3的SSR服务端渲染场景下Node.js中没有window对象。你需要创建一个模拟的DOM环境常用的工具是jsdom。npm install jsdom然后在你的服务端入口文件如server.js或SSR相关文件中import { JSDOM } from jsdom; import DOMPurify from dompurify; const window new JSDOM().window; const purify DOMPurify(window); // 现在可以使用purify.sanitize(...) const clean purify.sanitize(dirtyHtml);在你的通用工具函数中需要做环境判断// src/utils/sanitize.ts import DOMPurify from dompurify; let purify DOMPurify; if (typeof window undefined) { // 服务端环境 const { JSDOM } await import(jsdom); const dom new JSDOM(); purify DOMPurify(dom.window); } export const sanitize (dirty: string) purify.sanitize(dirty);4.5 性能考量与缓存对于高频更新的内容如实时聊天频繁调用sanitize可能成为性能瓶颈。虽然DOMPurify很快但仍需注意对于相同的内容可以考虑缓存净化结果。如果内容变化是追加式的如聊天记录可以只净化新增的部分。在Vue的computed属性中使用是合理的因为Vue会进行依赖追踪和缓存。5. 常见问题、排查技巧与安全边界即使使用了DOMPurify也并非一劳永逸。以下是我在实践中总结的常见坑点和排查清单。5.1 净化后样式丢失或布局错乱问题净化后的HTML渲染出来样式全无布局混乱。原因DOMPurify默认的白名单非常严格可能移除了你的HTML中含有的class、style或特定标签如div、span。排查检查净化前的原始HTML字符串。检查你传递给DOMPurify.sanitize的配置对象确认ALLOWED_TAGS和ALLOWED_ATTR是否包含了所需内容。在开发环境下可以临时将净化后的字符串console.log出来对比净化前后差异。解决根据业务需求适当扩展白名单配置。如果样式完全由上层CSS类控制确保class属性在ALLOWED_ATTR中。5.2 链接的target和rel属性处理不当问题净化后的链接点击后可能在本页打开导致用户离开你的应用或者存在target_blank的安全风险。解决如果你想强制所有外链在新窗口打开并添加安全属性可以在净化后使用DOM操作或字符串处理来批量修改。DOMPurify的RETURN_DOM或RETURN_DOM_FRAGMENT配置可以返回DOM节点方便操作。const clean DOMPurify.sanitize(dirty, { RETURN_DOM_FRAGMENT: true, ALLOWED_TAGS: [a], ALLOWED_ATTR: [href] }); clean.querySelectorAll(a).forEach(a { a.setAttribute(target, _blank); a.setAttribute(rel, noopener noreferrer); }); // 然后将DOM片段插入或转换为字符串更精细的控制如只对外部链接修改需要自己解析href的域名。5.3 与Vue的响应式系统结合时出现无限循环问题在watch或computed中调用净化函数如果净化函数内部修改了依赖的响应式变量可能导致无限更新。解决确保净化函数是纯函数不产生副作用。将待净化的数据作为参数传入而不是在函数内部读取响应式状态。使用我们上面封装的useSanitized可以很好地管理这种依赖关系。5.4 误以为净化能解决所有安全问题重要提醒DOMPurify解决的是HTML注入导致的XSS。它不能防止存储型XSS如果恶意脚本已经通过未净化的输入存入了数据库净化前端显示只是治标。净化必须在数据入库前进行至少要在后端做一次。前后端双重净化是黄金标准。基于DOM的XSS如果JavaScript代码直接使用innerHTML或eval()等操作未净化的数据DOMPurify也帮不上忙。需要避免不安全的DOM操作。其他Web漏洞如SQL注入、CSRF、文件上传漏洞等。5.5 配置错误导致规则被绕过问题自定义配置时错误地允许了危险标签或属性。案例为了支持“自定义表情”允许了img标签的onerror属性。原则遵循最小权限原则。只开放业务必需的功能。每次修改白名单都要问自己这个标签/属性是否绝对必要有没有更安全的替代方案5.6 测试你的净化策略不要相信“应该没问题”。建立测试用例单元测试为你的sanitize函数编写测试输入各种已知的XSS攻击向量断言输出是安全的或已被移除。使用在线XSS测试工具或Payload清单进行手动测试。考虑在代码审查中将安全配置的变更作为重点审查项。将DOMPurify集成到Vue3项目中更像是在数据流动的管道中安装了一个高效可靠的过滤器。它不能替代全面的安全开发意识但能为你的应用抵御绝大部分前端HTML注入攻击。记住安全是一个过程而不是一个产品。保持依赖库的更新关注安全社区动态定期审查你的安全配置才能让你的Vue3应用在享受开发效率的同时筑起坚固的安全防线。
