Vitest 安全模型与漏洞报告指南：从威胁模型到实践防护

Vitest 安全模型与漏洞报告指南：从威胁模型到实践防护

【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest

导读

本文以 Vitest 官方安全策略（SECURITY.md）为骨架，系统梳理 Vitest 的信任边界（Trust Boundary）、威胁模型（Threat Model）、安全边界内外的问题分类、漏洞上报流程，并结合仓库源码深入剖析 dev server 文件系统边界、浏览器命令接口、API Token 防护等底层实现。读完本文，你将掌握：Vitest 官方认可的漏洞范围是什么、哪些问题不在其安全承诺之内、如何安全地使用 dev server 与浏览器端测试能力，以及发现真实漏洞时应如何上报。

一、安全策略概述与受支持版本

Vitest 的官方安全策略文件（SECURITY.md）篇幅不长但结构完整，共分为四个部分：Supported Versions（受支持版本）、Threat Model（威胁模型）、Reporting a Vulnerability（漏洞上报）以及安全建议。

关于受支持版本，官方策略明确说明：请查阅文档中的 Releases 发布页 获取当前受支持的 Vitest 版本信息。其核心建议是：始终使用最新版本的 Vitest 及其官方插件。由于新漏洞的发现相对罕见，保持版本最新是让测试工具链保持安全的最简单手段。这与大多数现代开源工具的安全策略一致——只有仍在维护周期内的版本才会收到安全修复。

二、威胁模型：Vitest 信任什么、不信任什么

威胁模型是整个安全策略的灵魂。它回答了最关键的问题：什么样的报告才被官方认定为"Vitest 漏洞"。官方给出的判定标准是：

一个报告只有在"无需先攻破某个受信任元素"的情况下才能被认定为 Vitest 漏洞。

换句话说，攻击者必须先付出代价突破信任边界，其后续行为才可能被计入 Vitest 的安全承诺。官方同时明确：威胁模型之外的真实问题仍会被修复，只是不会被当作安全漏洞处理（例如不会签发 CVE 或安全通告）。Vitest 的威胁模型很大程度上参考了 Vite 官方的安全策略。

2.1 不被信任的对象（What Vitest Does Not Trust）

Vitest 不信任的对象只有一类：

网络数据与不受信任的客户端（Network data and untrusted clients）

基于 Vite dev server 构建的集成层，必须把入站请求视为潜在恶意请求，包括畸形请求，以及来自其他 Web 源（例如开发者浏览器中打开的恶意页面）的请求。这里的关键细节是威胁模型对"攻击者"的精确定义：

Vitest 要防御的不受信任客户端，是通过开发者自己的浏览器访问到 localhost 绑定 dev server 的客户端，而不是任意的网络对端。

这一点非常重要：浏览器发起的、能够到达 localhost 绑定服务器的请求始终在范围内（即使开发者没有做任何端口转发）。而如果开发者自己主动把 dev server 暴露到网络（见下文"开发者主动网络暴露"），则这种可达性造成的后果不再属于 Vitest 的漏洞范畴。

2.2 被信任的对象（What Vitest Trusts）

与不信任对象的单一形成鲜明对比，Vitest 信任四类对象：

1. 开发者及其基础设施：调用 Vitest 的人，以及他们使用的环境（本地工作站、CI runner、容器、操作系统、Node.js 运行时），均假设处于开发者控制之下并已妥善加固。
2. 配置与插件：vite.config.*或vitest.config.*中的一切、这些文件导入的代码、CLI 参数，以及所有插件及其传递依赖，都被视为开发者编写的内容，因此受信任。
3. 项目文件与依赖：项目引用的所有源文件、资源、已安装的包（包括node_modules里的所有内容）都是受信任的。
4. 开发者配置的网络目标：开发者显式配置的出站连接（例如server.proxy中的代理规则）因由开发者主动选择而受信任。

这一信任划分是后续所有"范围内 / 范围外"分类的逻辑基础。

三、各服务组件的安全边界

3.1 Dev Server

关于 dev server，官方策略给出四条边界：

• 可用性问题不视为漏洞（Availability issues are not considered vulnerabilities）：拒绝服务类问题不在安全承诺内。
• server.fs边界内的文件预期可被客户端访问：这是 dev server 文件系统隔离的核心语义。
• 文件是否存在是"不可隐藏"的：由于开发工具的本质，暴露文件存在性不视为漏洞。
• Vite 代码本身引发的漏洞应上报给 Vite 官方安全通告：Vitest 只对自身集成层负责。

其中server.fs边界在源码中有直接体现。在 resolveConfig.ts 中，Vitest 在解析完根 Vite 配置后会主动强化文件系统边界：

rootViteConfig.server.fs.allow.push( ...resolveFsAllow(rootViteConfig.root, rootViteConfig.configFile), ) rootViteConfig.server.fs.deny.push(API_TOKEN_FILE)

即：向fs.allow追加基于 root 与配置文件推导出的允许访问目录，同时把 API Token 文件（API_TOKEN_FILE，定义在 apiToken.ts，值为.vitest-secret-token）强制加入fs.deny黑名单，确保 dev server 在任何情况下都不会把 Token 文件内容暴露给浏览器端客户端。

文件系统访问的最终判定逻辑在 vite.ts：

if (!config.server.fs.strict) { return true } const filePath = fsPathFromUrl(url) return isFileLoadingAllowed(config, filePath)

server.fs.strict（严格模式）未开启时直接放行；开启后则把请求 URL 解析为文件路径，再交给isFileLoadingAllowed检查是否在允许范围内。这正是"构造恶意 URL 越过server.fs边界读取文件"这类漏洞（见下文 GHSA-8gvc-j273-4wm5）的防线所在。文件路径的解析逻辑（/@fs/前缀与 Windows 盘符处理）也在同一文件中（vite.ts），是 URL 到磁盘路径映射的规范化基础。

3.2 Preview Server 与 Build

官方明确声明：Vitest 不使用 Vite 的 preview server，也不使用 Vite 的buildAPI 构建文件。因此与 preview server 或 build 相关的漏洞应上报给 Vite，而非 Vitest。

四、漏洞范围判定：范围内示例与范围外示例

4.1 范围内（in scope）示例

官方列举了四类典型漏洞：

1. 构造 URL 使 dev server 返回server.fs边界之外的文件内容——典型案例如通过构造 HTTP 请求绕过server.fs.deny的 GHSA-8gvc-j273-4wm5。
2. 构造 URL 使 Vitest 在浏览器中执行任意代码——典型案例如?otelCarrier查询参数的 XSS 漏洞 GHSA-2h32-95rg-cppp 中的otelCarrier: { __VITEST_OTEL_CARRIER__ }），随后 orchestrator.ts 通过this.traces.getContextFromCarrier(...)从载体恢复追踪上下文，而追踪载体的读写能力定义在 traces.ts（getContextCarrier/getContextFromCarrier一对方法）。正是因为该值来源于 URL 查询参数且被浏览器端消费，它成为注入攻击面的典型例子，也解释了为何 XSS 修复被纳入安全通告。
3. 缺少或可绕过的 origin / host 校验，使跨源页面能够访问 dev server 端点，进而造成机密性或完整性损害。
4. 跨源页面打开到 dev server 的 WebSocket 连接，注入 HMR 消息，在开发者机器上执行任意 JavaScript，或绕过内置 Commands API 的保护层。

第 4 类直接指向浏览器端 Commands API 的安全职责。从源码看，命令层确实存在显式的输入校验与信任声明：浏览器会话的建立（sessions.ts）会记录 session 与项目绑定关系，而会话参数中即包含otelCarrier字段（sessions.ts），说明该值从创建阶段就进入服务端状态。官方文档 browser.commands 是配置自定义浏览器命令的入口——而自定义命令正因为"完全受信任"（见下节），其防护边界才尤为重要。

4.2 范围外（out of scope）示例

范围外共分六类，逐一说明：

1. 恶意插件、自定义命令或依赖（CWE-1357）：插件、配置文件、通过browser.commands配置的自定义浏览器命令及其依赖树，在开发期以完全信任运行。被攻陷的插件或自定义命令如果窃取数据、在未校验浏览器输入的情况下暴露特权访问、或执行任意代码，这属于供应链或项目代码问题，而非 Vitest 漏洞。这也解释了为什么server.fs.deny强制排除 Token 文件、为什么官方要求"仅从受信任的来源安装依赖"。
2. 应用自身输出中的安全问题：打包后应用里的 XSS、CSRF、CSP 配置错误等缺陷由应用作者负责。Vitest 会转换代码，但除了自身注入的代码外，不保证输出结果的安全属性。
3. 读取配置路径内的文件（CWE-427）：Vitest 预期能读取项目配置使其可达的任何文件。把 Vitest 指向包含敏感资料的目录是一种配置选择，不是 Vitest 漏洞——这与上文"server.fs边界内文件预期可访问"一脉相承。
4. 开发者主动网络暴露导致的可达性：Vitest 的网络防御目标是通过开发者浏览器访问 localhost 绑定 dev server 的攻击者（如恶意跨源页面），而非任意网络对端。如果开发者通过端口转发、反向代理或隧道、绑定公共接口（如--host参数）、或将服务器置于共享/不受信任网络上而使 dev server 对其他客户端可达，这种暴露属于开发者管理的基础设施选择，由此可达性带来的访问或特权行为不在范围内。但浏览器发起的、无需此类暴露即可到达 localhost 绑定服务器的请求仍在范围内。
5. 攻击者控制配置（CWE-15）：能修改环境变量、CLI 参数或vite.config.*/vitest.config.*的攻击者，已经控制了受信任输入，其控制行为的后果不在范围内。
6. 运行时或操作系统缺陷：Node.js、操作系统内核或其他平台级组件的漏洞不视为 Vitest 漏洞。

这六类范围外条目与第二节的"信任对象"精确对应，构成了完整的威胁模型闭环。

五、安全使用实践建议

结合威胁模型与源码实现，日常使用 Vitest 时可遵循以下实践：

1. 保持最新：始终使用最新版本的 Vitest 及其官方插件，及时跟进 Releases 发布页 与安全通告。
2. 约束 dev server 暴露面：不要轻易使用--host绑定公共接口，避免端口转发、隧道或反向代理把 localhost 服务暴露给不受信任的网络。威胁模型对"开发者主动暴露"造成的后果不予承诺。
3. 重视server.fs边界：server.fs.strict与allow/deny列表是文件读取的闸门（见 vite.ts 与 resolveConfig.ts），请勿把含敏感资料的目录加入 allow 列表。
4. 只信任自己的配置与插件：vite.config.*、vitest.config.*及其导入的代码、CLI 参数、插件与依赖树都按完全信任运行（CWE-1357、CWE-15 均不在范围内），务必只安装可信来源的依赖。
5. 浏览器命令注意输入校验：通过browser.commands配置的自定义命令拥有完全信任，其代码应对浏览器端传入的输入做严格校验，防止被恶意页面利用（对应范围内第 4 类 WebSocket/HMR 注入风险）。
6. 应用安全问题回归应用层：不要期望 Vitest 修补打包产物中的 XSS/CSRF/CSP 缺陷，这属于应用作者职责。

六、如何上报漏洞

官方上报流程非常明确：

请通过 https://github.com/vitest-dev/vitest/security 打开私有漏洞报告（private vulnerability report）。除非上游漏洞的代码被捆绑进了 Vitest 的包中，否则请不要上报上游漏洞。

两点值得强调：

• 必须在私有渠道上报，不要在公开 issue 中披露漏洞细节；
• 只有捆绑在 Vitest 包中的上游代码才向 Vitest 上报，否则应分别上报给对应上游项目（例如 Vite 代码引发的漏洞上报给 Vite 安全通告）。

结语

Vitest 的安全模型一句话概括就是："开发者及其配置完全可信，来自浏览器的网络输入默认可疑，开发者主动造成的网络暴露由其自行负责。"理解信任边界是正确使用该框架的前提——它决定了哪些问题值得创建安全通告、哪些问题应当回归项目自身。结合 SECURITY.md 的官方定义与本文引用的源码证据（resolveConfig.ts、vite.ts、sessions.ts、esm-client-injector.js），你可以在实际使用中精准判断哪些行为在保护范围之内，并安全地利用 dev server 与浏览器端测试能力。

【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest