feat(core): harden build-mode auth with a per-process capability token - #553
Merged
Conversation
@vitejs/devtools
@vitejs/devtools-kit
@vitejs/devtools-oxc
@vitejs/devtools-rolldown
@vitejs/devtools-vite
@vitejs/devtools-vitest
commit: |
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
In build mode, Vite DevTools previously disabled its client-auth gate entirely, so every accepted WebSocket client was marked trusted with no token — a trusted client could then drive the terminals RPC (spawn a shell → write), i.e. command execution as the Vite/Node user.
This keeps the zero-prompt build UX but stops trusting arbitrary clients by requiring a per-process, unguessable capability token that only a client able to read the locally-served connection metadata can present:
getBuildCapabilityToken), memoized per context, and register it as an always-trustedclientAuthTokensentry via devframe'screateInteractiveAuth. The OTP console banner is suppressed in this branch — trust comes purely from the token.auth: falseauto-trust shim, and register the interactive-auth RPC functions for this branch too (isBuildCapabilityAuth).authTokenso the same-origin build viewer picks it up automatically. The hub serves its own top-level__connection.jsonwithout a token, socreateDevToolsHubintercepts that one route and answers with the token-augmented meta; every other route falls through to the hub middleware untouched. A cross-origin loopback page can't read that metadata, so it never learns the token; anOrigin-less local process has no token to present either.The explicit
clientAuth: falseandVITE_DEVTOOLS_DISABLE_CLIENT_AUTH=trueopt-outs still fully disable the gate — only the implicit build-mode branch changes.isClientAuthDisabledno longer treats build mode as disabled.Linked Issues
fixes #552
Additional context
This is the DevTools-side half of the CWE-346/CWE-1385 hardening chain; the devframe loopback-origin classifier fix (devframes/devframe#319) closes the public-web path. Reviewers may want to focus on
packages/core/src/node/server.ts— the connection-meta interception is the one place the token reaches the top-level viewer.This PR was created with the help of an agent.