Skip to content

feat(core): harden build-mode auth with a per-process capability token - #553

Merged
antfu merged 1 commit into
mainfrom
fix/552-build-mode-capability-token
Sep 1, 2026
Merged

feat(core): harden build-mode auth with a per-process capability token#553
antfu merged 1 commit into
mainfrom
fix/552-build-mode-capability-token

Conversation

@antfubot

@antfubot antfubot commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

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:

  • Mint a per-process token (getBuildCapabilityToken), memoized per context, and register it as an always-trusted clientAuthTokens entry via devframe's createInteractiveAuth. The OTP console banner is suppressed in this branch — trust comes purely from the token.
  • Install the real auth handler in build mode instead of devframe's auth: false auto-trust shim, and register the interactive-auth RPC functions for this branch too (isBuildCapabilityAuth).
  • Bake the token into the emitted connection metadata's authToken so the same-origin build viewer picks it up automatically. The hub serves its own top-level __connection.json without a token, so createDevToolsHub intercepts 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; an Origin-less local process has no token to present either.

The explicit clientAuth: false and VITE_DEVTOOLS_DISABLE_CLIENT_AUTH=true opt-outs still fully disable the gate — only the implicit build-mode branch changes. isClientAuthDisabled no 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.

@pkg-pr-new

pkg-pr-new Bot commented Sep 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

@vitejs/devtools

npm i https://pkg.pr.new/@vitejs/devtools@553

@vitejs/devtools-kit

npm i https://pkg.pr.new/@vitejs/devtools-kit@553

@vitejs/devtools-oxc

npm i https://pkg.pr.new/@vitejs/devtools-oxc@553

@vitejs/devtools-rolldown

npm i https://pkg.pr.new/@vitejs/devtools-rolldown@553

@vitejs/devtools-vite

npm i https://pkg.pr.new/@vitejs/devtools-vite@553

@vitejs/devtools-vitest

npm i https://pkg.pr.new/@vitejs/devtools-vitest@553

commit: 9eaf5da

@antfu
antfu merged commit acb2a7a into main Sep 1, 2026
10 checks passed
@antfu
antfu deleted the fix/552-build-mode-capability-token branch September 1, 2026 05:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Harden build-mode DevTools auth: require a capability token instead of disabling client auth

2 participants