Is the VITE_ prefix convention enough to keep secrets out of a Vite client bundle?

Answer

No. The VITE_ naming convention only tells Vite which variables to inline; it does not prevent a developer from accidentally prefixing a secret, and it offers no guard against sensitive files placed in public/. Additional checks are required to keep secrets out of the shipped bundle.

Why the convention isn’t enough

• Vite replaces any import.meta.env.VITE_* reference with the variable’s value during vite build. If the variable name starts with VITE_ but holds a secret, that secret becomes part of the final JavaScript and is visible to anyone inspecting the bundle.
• The convention is purely a naming rule; there is no built‑in mechanism to block or warn about disallowed values.
• Files in public/ are copied verbatim to the output root with no filtering, so a sensitive file dropped there will persist across builds until manually removed.

Recommended steps for a client‑only SPA

1. Whitelist allowed variables – add a lint rule or custom Vite plugin that errors when import.meta.env is accessed with a name not in an approved list (e.g., only VITE_API_URL, VITE_APP_VERSION).
2. Scan the built output for patterns – in CI, run a grep‑like search for common secret markers (API keys, tokens, passwords) inside dist/. Example command:

   # Adjust patterns to your secrets
   if grep -rE "API_KEY|TOKEN|SECRET|PASSWORD" dist/; then
     echo "Potential secret found in bundle"
     exit 1
   fi
   

3. Use a plugin that enforces the prefix – vite-plugin-env-only (or similar) can be configured to fail the build if any non‑VITE_ variable is referenced.
4. Keep secrets out of public/ – treat the folder as public assets only. If you need to exclude specific files, move them outside public/ before the build (e.g., a script that temporarily renames or deletes them) or use a custom Vite plugin that filters the copy step.

Public folder – manual audit is the default

Vite provides no built‑in exclude mechanism for public/. The safest approach is to keep the folder free of sensitive files and to add a CI step that verifies no disallowed files appear after the build:

# Example: ensure no .key or .pem files are present
if find dist -type f -name "*.key" -o -name "*.pem" | grep -q .; then
  echo "Sensitive file found in public output"
  exit 1
fi

Missing diagnostic detail that could change the recommendation

Are you building for a client‑only SPA, or are you also using Vite’s SSR or library mode? In SSR/library modes the env inlining behavior differs, and additional checks may be needed for server‑side bundles.