new·Earn with mozg — 20% of every monthSend somebody here and take a fifth of every plan payment they make, for as long as they keep paying — not a bounty on the first invoice. Your handle is the link, the window is thirty days, and the commission lands on your balance the second they pay. Free to join: if you have signed in, you already have the link. mozg.sh/earnall news →
mozg.beta
Sign in

Vitest · API reference · all subjects

security

13 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

In-scope Vitest vulnerabilities: cross-origin and origin validation

Vulnerabilities in scope include: missing or bypassable origin or host validation that allows a cross-origin page to access dev-server endpoints causing confidentiality or integrity issues; a cross-origin page opening a WebSocket to the dev server and injecting HMR messages that execute arbitrary JavaScript on the developer's machine or bypass the built-in Commands API's protective layer.

Vitest threat model: what is trusted

Vitest trusts: developers and their infrastructure (local workstations, CI runners, containers, operating system, Node.js runtime); everything in vite.config.* or vitest.config.*, the code they import, CLI flags, and all plugins with their transitive dependencies; all source files, assets, and installed packages including node_modules; and developer-configured outbound network targets like proxy rules in server.proxy.

Vitest threat model: what is not trusted

Vitest does not trust network data and untrusted clients. The integration built on Vite's dev server must treat inbound requests as potentially hostile, including malformed requests and requests from other web origins such as a malicious page open in the developer's browser. The untrusted client is one reaching a localhost-bound dev server through the developer's own browser, not an arbitrary network peer.

Vitest dev server security scope

Availability issues are not considered vulnerabilities. Files within the configured server.fs boundary are expected to be accessible to clients. File existence is not hidden and cannot be hidden due to the development tool nature, so exposing file existence is not considered a vulnerability. Vulnerabilities in Vite's code should be reported to Vite's security advisory.

Vitest preview server and build security scope

Vitest does not use Vite's preview server and does not build files using Vite's build API. Any vulnerabilities in preview server or build functionality should be reported to Vite.

In-scope Vitest vulnerabilities: crafted URL attacks

Vulnerabilities in scope include: a crafted URL that causes the dev server to return file contents outside the server.fs boundary, such as server.fs.deny being bypassed with a crafted HTTP request (GHSA-8gvc-j273-4wm5); a crafted URL that causes Vitest to run arbitrary code in the browser, such as the ?otelCarrier search query XSS vulnerability (GHSA-2h32-95rg-cppp).

Out-of-scope: malicious plugins, commands, and dependencies

Plugins, config files, custom browser commands configured through browser.commands, and their dependency trees run with full trust during development. A compromised plugin or custom command that exfiltrates data, exposes privileged access without validating browser-provided input, or executes arbitrary code is a supply-chain or project-code concern, not a Vitest vulnerability (CWE-1357).

Out-of-scope: application security output

Security flaws such as XSS, CSRF, or CSP misconfigurations in the bundled application are the responsibility of the application author. Vitest transforms code but does not guarantee the security properties of the output beyond the code it injects itself.

Out-of-scope: reading files within configured paths

Vitest is expected to read any file the project's configuration makes reachable. Pointing Vitest at a directory that contains sensitive material is a configuration choice, not a Vitest vulnerability (CWE-427).

Out-of-scope: developer-initiated network exposure

Vitest's network defenses target attackers reaching a localhost-bound dev server through the developer's own browser, not arbitrary network peers. If the dev server becomes reachable to other clients because the developer port-forwarded it, fronted it with a reverse proxy or tunnel, bound it to a public interface using --host, or placed it on a shared or untrusted network, that exposure is a developer-managed infrastructure choice and is out of scope.

Out-of-scope: attacker with control over configuration

An attacker who can modify environment variables, CLI flags, or vite.config.*/vitest.config.* already controls a trusted input. Any consequences of that control are out of scope (CWE-15).

Out-of-scope: runtime and OS bugs

Vulnerabilities in Node.js, the OS kernel, or other platform-level components are not considered a vulnerability in Vitest.

Vitest vulnerability reporting

To report a vulnerability, open a private vulnerability report at https://github.com/vitest-dev/vitest/security. Do not report upstream vulnerabilities unless the code is bundled in Vitest's package. Always use the latest versions of Vitest and its official plugins to ensure the application remains as secure as possible.

Give your agent this brain