fix(ui)!: harden UI API access#10583
Merged
sheremet-va merged 32 commits intoJun 19, 2026
Merged
Conversation
Co-authored-by: Codex <[email protected]>
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Collaborator
Author
|
Still brainstorming and cookie might indeed work alright. Here is possible flow:
|
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
AI-Agent: Opencode
hi-ogawa
commented
Jun 18, 2026
When the API token is generated for the first time, no browser holds the auth cookie yet, so open `/__vitest__/?token=...` to authenticate. On subsequent runs, open the clean URL so macOS tab reuse keeps working. AI-Agent: Opencode
hi-ogawa
commented
Jun 19, 2026
`resolveApiToken` now returns the resolved `tokenPath` so the test can target the actual on-disk token file, assert it exists, and confirm the Vite dev server blocks serving it (403). AI-Agent: Opencode
AI-Agent: Opencode
…fix/ui-api-capability-url
Drop the duplicated '.vitest-secret-token' literal in the browser plugin and import the single source of truth from vitest's apiToken module via a relative-src import, keeping the constant internal (no public vitest/node API surface). AI-Agent: Opencode
hi-ogawa
commented
Jun 19, 2026
hi-ogawa
commented
Jun 19, 2026
Rename the constant to reflect it is the token filename, and reuse it when building the token file paths instead of repeating the literal. AI-Agent: Opencode
AI-Agent: Opencode
Replace the hand-rolled cookie parse/serialize with the jshttp `cookie` library (bundled via devDependency). This makes encode/decode symmetric and removes the bespoke parsing. AI-Agent: Opencode
hi-ogawa
marked this pull request as ready for review
June 19, 2026 03:55
sheremet-va
approved these changes
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
As described in v5 breaking change doc, this changes so that Vitest UI now requires authentication for accessing
/__vitest__/. First time user authenticates through accessing/__vitest__/?token=..., then middleware check token and persists it as cookie, then later/__vitest__/access will check that cookie. To make requiredtokenstable between vitest invocation, it's now generated once in.local/share/vitest/.vitest-secret-token(and alike on macos and windows).The rational of the change is that, even though the Vitest API usage is purely for devtools, what's available on the network through
localhost:51204/__vitest__/is immediately RCE (remote code execution) and it's reasonable to protect from arbitrary network access as a basic security posture. In retrospect, if we were to have this (together with #10522), the past vulnerabilities related to API didn't exist.This is also partly because, intended or not, our security policy frames this way https://github.com/vitest-dev/vitest/blob/main/SECURITY.md#what-vitest-does-not-trust
(Not sure yet though if I want to go through all vulnerability patch process. We can say this is a matter of interpretation since we do call out exposing allowExec/allowWrite in non localhost shouldn't be done in documentation.)
TODO
Example:
Screen.Recording.2026-06-18.at.17.41.03.mov
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.Changesets
feat:,fix:,perf:,docs:, orchore:.