API key visible in browser JavaScript bundle: how to hide it

Likely causes, most common first

Check and fix it, step by step

1. Search the client build output for secret names

   Grep the folder your build writes browser JavaScript to. Search for the names in your env files and the key prefixes your providers use. A match in the client output means that text shipped to browsers.

   grep -rlE 'API_KEY|SECRET' path/to/client-build

   Docs: nextjs.org →

2. List variables that carry a public prefix

   Look through your env files for names starting with NEXT_PUBLIC_ or VITE_. Vite exposes VITE_ variables in client-side source code, and Next.js can inline NEXT_PUBLIC_ values into the browser bundle, so a key in that list may be exposed. To confirm, search the build output for the key's value.

   grep -rnE '^(NEXT_PUBLIC|VITE)_' .env*

   Docs: vite.dev →

3. Trace the import that pulled the module in

   Open the file that contains the match and find which module imports it. Follow the chain up to a file marked "use client", because Next.js includes that file's imports in the client bundle.

   Docs: nextjs.org →

4. Mark the server config module server-only

   Add import 'server-only' at the top of the module that holds secret names and formats. A client import then fails the build instead of shipping. Next.js treats installing the package as optional, but you can install it if your lint rules flag extraneous dependencies.

   import 'server-only'
   
   export const config = {
     apiKey: process.env.API_KEY,
   }

   Docs: nextjs.org →

5. Split public config from secrets

   Put the values the browser needs in their own module, built from NEXT_PUBLIC_ variables. Read secrets in one server-side layer and return the fields a component needs.

   // lib/public-config.ts: safe for client imports
   export const publicConfig = {
     analyticsId: process.env.NEXT_PUBLIC_ANALYTICS_ID,
   }

   Docs: nextjs.org →

6. In Vite, drop the prefix and call the provider from a backend

   Rename the variable without the VITE_ prefix and stop reading it in browser code. Have the browser call a backend server or a serverless/edge function that holds the key and talks to the provider.

   console.log(import.meta.env.VITE_SOME_KEY)  // "123", reaches the client
   console.log(import.meta.env.DB_PASSWORD)    // undefined

   Docs: vite.dev →

7. Revoke the exposed key, then rebuild

   Revoke the key that shipped, issue a new one and set it on the server. Next.js fixes NEXT_PUBLIC_ values at build time, so rebuild and redeploy to replace the old output. Add secrets detection to your repository tooling to catch a repeat.

   Docs: cheatsheetseries.owasp.org →

Quick check: grep -rlE 'API_KEY|SECRET' path/to/client-build # a hit means that text shipped to browsers

How often this shows up in our data

3 of the 701 verified cases from the last 12 months in our data match this symptom (0.4%). The most common cause was “A server config module is imported by client code” (1 of 3); 1 didn't show which cause. How we collect and verify cases.

Questions

Sources

• Next.js: How to use environment variables (nextjs.org)
• Next.js: Server and Client Components (nextjs.org)
• Next.js: How to think about data security (nextjs.org)
• Vite: Env Variables and Modes (vite.dev)
• OWASP Secrets Management Cheat Sheet (cheatsheetseries.owasp.org)

Every cause and step above was checked against these pages on 13 Oct 2026.

The broader pattern

This is one symptom of a wider failure pattern: API endpoints answer without login and secrets ship in the bundle. The guide covers every cause we see for it, on any stack.