Unexpected client-side exposure of Nuxt runtimeConfig values

Question

When auditing a Nuxt 3 application, some configuration entries that were intended for server‑only use appear in the generated client bundle, suggesting they are being treated as public runtime config.
The goal is to understand why values without the NUXT_PUBLIC_ prefix are being included in the client‑side JavaScript and to confirm whether they are actually exposed to end users.
Constraints include the project’s use of the runtimeConfig API, the absence of any build‑time warnings, and the need to avoid exposing secrets such as API keys or tokens.
What causes non‑prefixed config keys to be bundled into the client payload?
How can developers verify which keys are marked as public at build time without manually inspecting the bundle?
Are there any linting or build‑time checks that can prevent accidental inclusion of server‑only values in runtimeConfig.public?

Tasadduq Burney · Answer

Likely explanation
In Nuxt 3 the runtimeConfig object is split at build time into a private section (server‑only) and a public section that is sent to the browser. Keys that do not have the NUXT_PUBLIC_ prefix remain private, but if any client‑side code imports or references the whole runtimeConfig (e.g., calling useRuntimeConfig() without destructuring a specific key) the bundler cannot tree‑shake those properties and may keep them in the generated JavaScript bundle. Consequently those values appear in the client payload even though they were not marked public.
Confirmed facts from Nuxt’s build process

Only the keys listed under runtimeConfig.public (or those prefixed with NUXT_PUBLIC_) are copied into the __NUXT_CONFIG__ JSON that is injected into the HTML.
  Private keys are omitted from that JSON unless the developer manually assigns them to runtimeConfig.public in nuxt.config.ts.
  In development mode (nuxt dev) the full config is often emitted, which can give a false sense of safety; the production build is the authoritative test.

Steps to verify which keys are exposed

Build the application for production: npx nuxi build
  Search the generated client bundle for the config string: grep -r '__NUXT_CONFIG__' .output/public
  Extract and view the JSON payload (example using jq if available): grep -o '__NUXT_CONFIG__=.*' .output/public/**/*.js | head -n1 | sed 's/__NUXT_CONFIG__=//' | jq .
  Compare the listed keys with the set you expect to be public; any extra keys indicate accidental exposure.

Build‑time checks to prevent accidental exposure

Enable the ESLint rule @nuxtjs/eslint-plugin-nuxt/nuxt-no-public-runtime-config (or create a custom rule) that flags any use of useRuntimeConfig() without destructuring to a specific key.
  Add a validation snippet in nuxt.config.ts that compares Object.keys(runtimeConfig) against Object.keys(runtimeConfig.public) and warns if private keys are present in the public set.
  Run npx nuxi build --analyze to visualize the bundle and verify that no unexpected strings appear in the client chunks.

Unexpected client-side exposure of Nuxt runtimeConfig values

1 answer

Likely explanation

Confirmed facts from Nuxt’s build process

Steps to verify which keys are exposed

Build‑time checks to prevent accidental exposure

Your perspective belongs here.

0 question comments