Vue.js安全攻防：从v-html到SSR的XSS漏洞与加固方案-平芜编程栈

想写这篇 Vue.js 安全的文章，是因为前阵子帮人看一个线上问题。一个后台管理系统，Vue 单页应用，服务端渲染也用上了，结果某天用户反馈“点开详情页就弹窗”。排查到最后，问题出在v-html上，而且那条数据居然是从接口直接返回的一段富文本。很多人觉得 Vue 模板默认转义了，XSS 已经很遥远，但现实里因为对框架的“安全边界”理解不透，反而更容易踩坑。

这篇文章我会从 Vue 前端本身的 XSS 攻击向量讲起，再切到服务端渲染场景下那些容易被忽略的风险点，最后给出一套能直接落地执行的加固方案。不管你是刚接手 Vue 项目的开发者，还是已经在做 SSR 改造的负责人，这篇内容都能当作一份排查手册来用。

1. Vue 默认防线到底防了什么，又漏了什么

1.1 模板插值确实做了转义，但它不是“消毒”

先明确一个基础结论：Vue 的模板插值{{ }}默认是会把内容当作纯文本插入的。比如{{ userInput }}，即使userInput是<img src=x onerror=alert(1)>，最终渲染出来也是一段普通文本，浏览器不会把它解析成 HTML 标签。

这个机制的本质是：Vue 在把数据变成 DOM 节点时，不是用innerHTML去拼接，而是通过文本节点的方式写入。浏览器在创建文本节点时，天然不会去解析其中的 HTML 结构。所以只要你不主动使用v-html，绝大多数“纯文本型注入”在 Vue 里是打不穿的。

但这里有个认知陷阱：转义和消毒是两码事。转义解决的是“内容会不会被当成 HTML 语法解析”，它只改变了输出上下文。而消毒解决的是“这段内容本身是不是危险”，它需要识别并删除危险片段。Vue 只帮你做了前者，后者从来没有承诺过。

我见过不少团队把“用了 Vue”等同于“不需要过滤 XSS”，这是很危险的。Vue 的安全边界是模板层，不是数据层。数据进入组件之前有没有被恶意构造、渲染时被放进了哪个上下文，这些都需要开发者自己把关。

1.2 转义的作用范围有限，千万别把边界当成全部

Vue 模板插值可以防止 HTML 标签注入，但它管不了所有 HTML 属性场景。

举个例子：

<a :href="userUrl">跳转</a>

如果userUrl的值是javascript:alert(document.cookie)，Vue 会原封不动地把这个值放到href属性里。用户在页面里点击这个链接时，浏览器会执行 JavaScript 脚本。Vue 不会因为你用了属性绑定就主动去拦截javascript:伪协议，因为这属于 URL 语义层面的校验，框架没义务也没办法判断你的业务里什么链接是合法的。

其他属性同样如此。比如<img :src="userSrc">、<iframe :src="userFrame">，甚至是一些事件监听相关的属性拼接，一旦用户输入的字符串进到这些位置，安全责任就转移到了开发者身上。

还有一个日常容易忽视的位置：<style>标签内部。Vue 的:style支持对象语法，样式属性值如果来自用户输入，同样需要约束。某些老浏览器下，CSS 表达式、url()里的 JavaScript 伪协议在特定场景会造成脚本执行。即便现代浏览器已经封堵了大部分，点击劫持、视觉欺骗这类问题是样式层永远存在的风险。

所以我把 Vue 的默认防线总结成三句话：

{{ }}插值是安全的文本输出通道。
属性绑定不负责语义安全，尤其是href、src这类带 URL 语义的属性。
任何把用户内容变成“可执行上下文”的行为，比如v-html、动态模板编译、事件字符串拼接，都是开发者自己划进风险区的。

2. 逐个拆解 Vue 前端常见的 XSS 攻击向量

2.1 v-html：最容易被人直接拿去插入用户内容的指令

v-html是 Vue 项目里 XSS 的头号入口，这一点没有任何争议。官方文档也反复强调过，永远不要用v-html渲染用户提供的内容。

但在真实项目里，需求往往是这样的：后台管理系统需要展示富文本，内容是运营人员在编辑器里写的，可能还希望大家手动改过 HTML。于是有人顺手写了：

<div v-html="article.content"></div>

如果这份内容在进入接口前没有被彻底清洗，攻击者只需要在编辑器里贴一段<img src=x onerror=alert(document.cookie)>之类的代码，所有访问这篇文章的人都会中招。

更麻烦的是，富文本审核如果只做了标签黑名单，攻击者可以用各种绕过姿势：大小写混写、事件属性拼接、<svg>嵌套、<math>标签，甚至利用 HTML 解析器的宽容特性构造出黑名单完全覆盖不到的形态。

我的建议是：能用纯文本就坚决不用v-html。富文本类需求可以改用支持自定义渲染方案的编辑器，让编辑器输出结构化的 JSON 数据，前端用组件递归渲染，而不是保存一整段 HTML。如果历史数据已经存了 HTML，必须经过白名单机制的清洗库处理后再交给v-html。

<div v-html="safeHtml"></div>

import DOMPurify from 'dompurify' const safeHtml = computed(() => { return DOMPurify.sanitize(props.content, { USE_PROFILES: { html: true }, FORBID_TAGS: ['style', 'iframe', 'form', 'input'], FORBID_ATTR: ['style', 'onerror', 'onload'] }) })

2.2 href、src 和 javascript: 伪协议

这类问题在 Vue 项目里很典型，甚至比v-html更隐蔽，因为代码看着挺正常。

<a :href="item.link">{{ item.title }}</a>

item.link来自用户提交，用户提交了一个javascript:alert(1)，Vue 不会拦。点击链接之后，浏览器执行脚本，登录态被拿走。

攻击者为什么会选javascript:伪协议？因为很多开发者在做输入校验时习惯检查http://或https://开头，却忘了拦截javascript:、data:、vbscript:。只要你的过滤逻辑有任何遗漏，拼接javascript:alert(document.domain)往往就能打通。

处理方案有两个层面。第一个层面是入库时校验，强制业务字段必须是 http 或 https 协议。第二个层面是渲染前再校验，我是推荐双层的，因为历史数据未必都规范。

function isSafeUrl(url) { if (!url) return '' const parsed = new URL(url, window.location.origin) return ['http:', 'https:'].includes(parsed.protocol) ? url : '' }

new URL解析的好处是，它可以识别很多编码绕过。哪怕攻击者写成java\nscript:，标准库解析时也能还原出真实的协议。用字符串startsWith判断，很容易被各种空白符、控制字符绕过。

2.3 动态模板编译：把用户输入拼进组件

Vue 有一个很容易被忽略的入口：动态模板。

new Vue({ template: '<div>' + userInput + '</div>' })

或者运行时环境里用template选项拼接用户的输入。这种情况下，用户输入会被当作模板语法解析。如果说xss向量在v-html里只是“插入 HTML 标签”，那么动态模板里攻击者直接控制了组件的渲染结构。

攻击者可以构造这样的输入：

<img src=x onerror="alert(1)">

模板编译器在解析时，onerror会被当成事件属性，最终生成可执行的 HTML。更严重的是，如果攻击者能注入 Vue 指令，比如v-if、v-for，甚至v-on:click，那影响就不仅是弹窗了，还可能盗取用户操作权限。

为什么会有这种写法？一些团队为了快速实现低代码平台、动态表单配置，把后台传过来的 JSON 直接变成模板字符串去解析。这个思路本身有合理性，但一定要明确：动态模板编译等于把 Vue 的整个能力暴露给模板内容的生产者。如果生产者不可信，那就等于把服务器权限交了出去。

安全做法是：把动态配置抽象成数据，用代码组件去渲染。配置描述“这个位置是图片”，代码组件就去渲染图片；“这个位置是视频”，就去渲染视频。而不是把一整段模板字符串交给 Vue 解析。

2.4 样式绑定与点击劫持等隐蔽风险

v-bind:style和<style>标签里的用户内容，虽然通常不直接执行脚本，但实战中坑并不少。

一个比较常见的是点击劫持。攻击者构造一个透明图层覆盖在用户要点击的按钮上，用户以为自己点了“确定”，实际点了“删除”。如果你的样式绑定了用户可控的position、opacity、z-index，这类攻击会变得非常容易。

另一个场景是旧内核浏览器下的 CSS 表达式。虽然现代浏览器基本都不再支持，但兼容老环境的内网系统未必安全。CSS 层的 payload 也可以做数据窃取，比如通过background: url()把用户信息带出去，前提是页面里有用户可控的样式片段。

处理上不需要过度复杂，记住一条规则即可：用户输入永远不能直接成为样式名、选择器和 URL 值。样式值能走枚举就枚举，比如size: 'small' | 'medium' | 'large'，组件内部维护一套固定映射，用户传入的值只做索引查找，不要直接拼进样式对象。

3. 服务端渲染场景下的 XSS 风险与典型漏洞点

3.1 SSR 为什么会改变攻击模型

很多 Vue 项目做服务端渲染，是为了首屏速度和 SEO，但 SSR 引入的安全问题比 SPA 更值得仔细过一遍。

SPA 模式下，页面初始 HTML 往往只是一个空壳，真正的内容由浏览器执行 JavaScript 后渲染。XSS 攻击如果想在页面加载阶段发生，要么依赖外链脚本被篡改，要么依赖运行时才能触发的漏洞。而 SSR 模式下，服务端直接生成完整的 HTML 返回给浏览器。这意味着用户输入一旦进入服务端渲染的模板，最后输出的 HTML 就是“开箱即用”的攻击载荷，不需要等任何异步逻辑。

攻击面还扩大到了服务端代码。SSR 应用在服务端执行组件代码时，会调用 Vue 的渲染函数、生命周期钩子，如果这些代码里存在不安全的字符串拼接、网络请求携带了不可信的 URL，那么服务端本身也可能成为被攻击的数据管道。

还有一个很容易被忽略的点：SSR 输出的 HTML 通常会包含一段内联的初始状态数据window.__INITIAL_STATE__。这段数据是后端数据到前端代码的桥梁，如果写入时没有做针对性转义，它就等于在页面里插了一个脚本执行点。

3.2 v-html 在 SSR 中并不会获得额外保护

前面说v-html在纯前端项目里危险，到了 SSR 场景，同样的代码危险程度还会升级。

原因很简单：SPA 下如果v-html的内容是清洗后的，那客户端渲染出来的 DOM 就是清洗后的。而 SSR 下，服务端把 HTML 字符串直接输出到响应里，浏览器解析这段字符串时，不存在“Vue 再帮你转义一层”的可能。

看这个例子：

const app = createSSRApp({ template: '<div v-html="content"></div>', data() { return { content: '<script>alert(1)</script>' } } })

如果content未清洗，服务端输出的 HTML 中会直接包含<script>alert(1)</script>这段标签。浏览器在解析整个文档时会执行它。

我在实际项目里的处理原则是：SSR 项目和普通 SPA 项目用同一套清洗逻辑。也就是说，清洗不能只放在浏览器端，也不能只放在服务端，两端都要有。尤其是 SSR 项目，服务端输出前必须保证内容是干净的，因为浏览器这边根本没机会二次处理。

推荐的方式是把清洗逻辑做成一个纯函数，不依赖window或document，这样服务端和客户端都能调用。

import createDOMPurify from 'dompurify' import { JSDOM } from 'jsdom' const window = new JSDOM('').window const DOMPurify = createDOMPurify(window) export function sanitizeHtml(html) { return DOMPurify.sanitize(html, { ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'a', 'ul', 'ol', 'li'], ALLOWED_ATTR: ['href', 'title', 'target'] }) }

3.3 Hydration 差异带来的安全与稳定性问题

SSR 的页面在浏览器接管之前，先有服务端生成的 HTML。Vue 在客户端启动时会做一次“水合”，把事件监听和行为绑定到已有的 DOM 上。如果服务端渲染的 HTML 和客户端第一次渲染结果不一致，Vue 会尝试修正。

问题在于，修正过程本身也可能引入 XSS 风险。比如服务端输出的某个onclick属性是清洗过的，但客户端拿到同一份数据，又做了一次不同的清洗逻辑，导致两端结果不一致。这时 Vue 的修补逻辑可能会重新渲染该区域的 DOM，而这种重新渲染往往用的是客户端数据，如果客户端数据没有再清洗一遍，危险内容就被实际插入。

还有一类差异来自时间敏感数据。服务端渲染时看到的是数据 A，客户端启动时数据已经变成了攻击者可控的数据 B。如果组件里存在v-html="someField"，服务端对 A 做了清洗，客户端对 B 没清洗，这种差异会让攻击机会变得更大。

排查 hydraiton 差异并不难。打开浏览器的开发者工具，控制台出现Hydration completed but contains mismatches提示时，说明某个节点和客户端计算结果对不上。你在定位这类问题时，不要只当成普通的渲染 bug，还要追问一下：这个不一致的字段是谁提供的？值是怎么从服务端到客户端的？中间经过了哪些清洗逻辑？

3.4 状态序列化时发生的 script 标签逃逸

SSR 项目里最容易被低估的，就是“把服务端数据塞进<script>标签”的环节。

常见代码长这样：

<script> window.__INITIAL_STATE__ = {{{ initialState }}} </script>

initialState如果不是安全转义后的 JSON，而是一个包含</script>字符串的 JSON 对象，浏览器解析时会在</script>处提前结束标签，后续内容就变成了页面里的 HTML 标签。

举个最简单的例子。某用户的名字是</script><img src=x onerror=alert(1)>这一段，如果数据被 JSON.stringify 后直接塞进 script 标签：

<script> window.__USER__ = {"name":"</script><img src=x onerror=alert(1)>"} </script>

浏览器解析 HTML 时，会认为</script>是上一个脚本标签的结束。然后<img src=x onerror=alert(1)>就被当成了 HTML 节点，脚本执行。

这种问题在不做 SSR 的纯前端项目里不存在，因为数据在 JavaScript 变量里传递，不会被 HTML 解析器二次解释。但 SSR 改变了数据传输通道，原本安全的做法到了这里就失效了。

标准解法是转义 JSON 字符串中的 HTML 敏感字符。

function serializeState(data) { return JSON.stringify(data) .replace(/</g, '\\u003c') .replace(/>/g, '\\u003e') .replace(/&/g, '\\u0026') .replace(/=/g, '\\u003d') }

这样即使数据里有</script>，经过转义后也只是一段普通字符串，脚本标签不会被提前闭合。

更稳妥的做法是：不要把 JSON 直接输出到 script 标签，可以用textContent赋值。将状态放在一个 type 为特殊 MIME 的 script 标签里，然后用 JavaScript 读取其内容解析。

<script type="application/json" id="app-state"> {"name":"</script><img src=x onerror=alert(1)>"} </script>

浏览器不会执行非 JavaScript MIME 的 script 标签内容，天然避免了脚本逃逸。读取时用 JSON.parse 解析对应节点的 textContent。

3.5 内联脚本与 CSP 的关系

SSR 项目几乎离不开内联脚本。状态数据、首屏配置、环境变量都要以内联方式放到 HTML 里。CSP 配置稍有不慎，这些内联脚本要么无法执行，要么因为开启了unsafe-inline而导致整体防护形同虚设。

CSP 里有两个关键点：

script-src如果没有显式配置，会走default-src。
如果允许unsafe-inline，内联脚本都能执行，也就等于为 XSS payload 打开了一个大通道。

理想状态是script-src 'self'，外链脚本走自有域名，内联脚本使用 nonce 或 hash 方式放行。Vue SSR 输出内联脚本时，你可以给 script 标签加上 nonce 属性，然后在 CSP 里指定nonce-xxx。这样即便页面里被注入了额外的内联脚本，没有正确 nonce 也无法执行。

但要注意一个细节：Vue 的模板编译器在某些配置下需要new Function来生成渲染函数。这种情况下 CSP 需要unsafe-eval。如果项目同时要求严格 CSP 和运行时模板编译，你会遇到一个两难选择。我的建议是优先使用预编译模板，也就是在构建阶段完成编译，避免运行时依赖 eval。

4. 一份可直接落地的 Vue + SSR 加固清单

4.1 约定的 HTML 清洗接口

不管前端还是 SSR，最终都要落到“统一清洗”这件事上。最怕的是每个页面各写一套清洗逻辑，有的严格有的宽松，漏网之鱼就成了突破口。

我建议在项目里定义一个公共方法，封装清洗库，并固定白名单配置。每个页面不允许绕过它。

// shared/sanitize.js import createDOMPurify from 'dompurify' const config = { ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'a', 'ul', 'ol', 'li', 'blockquote'], ALLOWED_ATTR: ['href', 'title', 'class'], ALLOW_DATA_ATTR: false } export function sanitizeHtml(dirtyHtml) { return createDOMPurify().sanitize(dirtyHtml, config) }

同时安排两个阈值：一个用于富文本展示，一个用于普通文本字段。普通文本字段如果不需要解释 HTML，最优解是根本不让便宜 HTML 进入输出链路，在入口统一转义为纯文本。

4.2 URL 协议白名单与安全的跳转

针对javascript:伪协议，建立统一的 URL 校验函数。

export function safeUrl(raw) { if (!raw || typeof raw !== 'string') return '' const trimmed = raw.trim().replace(/[\u0000-\u001F\u007F]/g, '') try { const parsed = new URL(trimmed) return ['http:', 'https:', 'mailto:'].includes(parsed.protocol) ? trimmed : '' } catch { return '' } }

如果业务里确实允许mailto:或tel:，把对应协议加入白名单即可。这里的关键不是列举所有危险协议，而是只放行明确安全的协议集合。黑名单式的判断永远追不上编码变体，只有白名单才是可靠的。

在内容存储时，我也会对字段做一次协议校验，不合格的直接拒绝写入。渲染前再调用一次safeUrl，属于二次保险。不要嫌重复，安全本来就应该是多层叠加。

4.3 安全的 SSR 状态输出

SSR 状态注入统一走一个工具函数：

export function serializeState(data) { const json = JSON.stringify(data) return json .replace(/</g, '\\u003c') .replace(/>/g, '\\u003e') .replace(/&/g, '\\u0026') .replace(/=/g, '\\u003d') }

在模板里使用时：

<script> window.__INITIAL_STATE__ = {{{ serializeState(initialState) }}} </script>

如果你用的是基于 Vue 的某个 SSR 框架，也同样要注意它的序列化配置。比如它有一个默认的payload注入机制，如果源码里没有做上述转义，你可以在它序列化之后、输出之前再套一层处理。虽然不同框架的扩展方式不同，但核心逻辑是一样的。

4.4 合理配置 Content Security Policy

CSP 是最后一道防线，我的建议是每个 Vue SSR 项目都必须有，哪怕初期配置得宽松一点，也比完全没有强。

一个比较实用的起步配置：

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-随机值'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; frame-ancestors 'self'

style-src 'unsafe-inline'在 Vue 中往往没办法完全避免，因为动态样式绑定时会往元素上写 style 属性。但script-src能收紧就收紧。如果因为运行时模板编译需要unsafe-eval，优先考虑改造成预编译模板，不要为了省事把unsafe-eval长期暴露在线上。

CSP 的难点在于，它不能解决业务层所有漏洞，但它可以把一个还不错的攻击 payload 变成无效代码。比如v-html注入的<script>标签，在严格 CSP 下根本执行不了。这就给了你多一层缓冲，不至于一被绕过就马上沦陷。

4.5 团队层面的安全红线

安全方案落地，最大的阻力往往不是技术，而是团队习惯。我见过项目里有人为了省事，直接把接口返回的大段 HTML 原样渲染到v-html里，理由是“以前也是这么干的”。

你可以在团队规范里写明这三条红线：

用户可控数据禁止直接进入v-html，必须先走统一清洗函数。
用户可控数据做 URL 协议白名单校验后再进href、src。
SRR 状态输出必须走serializeState，禁止把原始 JSON.stringify 结果直接放进 script 标签。

这三条红线要写成 lint 规则或者 code review 必查项，不能只停留在口头强调。

5. 我实际踩过的问题和排查记录

5.1 一次“看上去安全”的富文本注入

有个后台项目，内容编辑页有比较完整的富文本控件，开发团队认为既然编辑器保存的是 HTML，那展示时就只能用v-html。我接手后做安全测试，直接在编辑器源码模式下贴入：

<a href="javascript:alert(document.cookie)">点我</a>

保存后刷新页面，点击这个链接，浏览器直接弹了 Cookie。当时团队第一反应是“我们富文本编辑器不是有过滤吗”，但过滤逻辑并不包含对href协议的白名单校验。

修复方案很简单：富文本保存前做协议白名单校验，展示时对 HTML 做白名单清洗。这里我也明白了另一个道理——富文本编辑器自身的安全措施，不能等同于业务层安全措施。编辑器过滤和业务层过滤是两个独立层次，一个都不能省。

5.2 Hydration mismatch 掩盖下的 XSS

另一个 SSR 项目出现了一个诡异现象：用户反馈某个资讯页偶尔闪烁一下，然后页面显示错乱。查日志发现控制台大量报 hydration mismatch。

后来定位到深层原因：服务端渲染时通过接口拿到资讯正文，套了一次清洗逻辑。客户端 hydration 时，又因为另一个安全插件对同一份正文做清洗，两套清洗规则不一致，导致服务端保留了某个合法class，客户端清洗后却删掉了，DOM 就产生了差异。

万幸这个案例没有实际执行脚本，但这个结构让我意识到：两端清洗逻辑必须统一，不仅是规则层面，最好连清洗库版本都保持一致，否则任何一端出现了不可预期的改动，差异就会成为新的攻击面。

5.3 快速排查 XSS 的检查清单

每次项目上线前，我会按下面这张表过一遍，效率很高：

检查项	检测方式	修复方案
v-html 使用点	全局搜索`v-html`，逐个确认数据来源	统一走清洗函数
href/src 属性绑定	搜索`:href`、`:src`，确认是否存在动态值	加协议白名单
script 标签注入状态	查看 SSR 模板中 JSON 是否被转义	使用 serializeState
内联脚本 CSP	浏览器控制台检查是否报 CSP 违规	配置 nonce
Hydration 差异	控制台查看 mismatch 警告	统一清洗逻辑