Your NEXT_PUBLIC secret is already in the browser bundle

In a Next.js app it’s easy to slip a secret (e.g., STRIPE_SECRET_KEY

, OpenAI API key, Supabase JWT) into a client‑side bundle. When a server component reads process.env.STRIPE_SECRET_KEY

it stays on the server, but copying that line into a client component causes the build to fail to resolve the variable. The common “quick fix”—renaming the variable with the NEXT_PUBLIC_

prefix—makes the value part of the JavaScript that every visitor downloads, turning a server‑only secret into a public leak.

Next.js environment variable scoping

NEXT_PUBLIC_

prefix are stripped from the client bundle at build time. They are only available in server‑side code (pages/api/*

, server components, getServerSideProps

, etc.). NEXT_PUBLIC_

prefix are injected into the client bundle and can be read from process.env

in any browser‑executed code.Accidental exposure

const stripeKey = process.env.STRIPE_SECRET_KEY;

from a server component to a client component (or a shared utility imported by both). STRIPE_SECRET_KEY

is undefined on the client. NEXT_PUBLIC_STRIPE_SECRET_KEY

. Why the leak is critical

KeyDrift performs a read‑only scan of your client bundle—no credentials are required—to locate hard‑coded secrets and environment variables that have been inlined. The scan cross‑references each detected credential with the tool that introduced it (e.g., Next.js, Replit, Cursor).

Typical output for a Next.js leak looks like:

[Critical] STRIPE_SECRET_KEY found in client bundle (tool: Next.js)
Location: static/chunks/pages/_app.js:1234
Recommendation: Move usage to a server component or API route.

KeyDrift also flags variables that have been renamed with the NEXT_PUBLIC_

prefix and marks them as high or critical depending on the credential type (e.g., Stripe secret key → critical).

// app/api/stripe/checkout/route.ts (server‑only)
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2023-10-16',
});

export async function POST(req: Request) {
  // server‑side logic only
}
js
// app/components/CheckoutButton.tsx (client component)
'use client';
import { useState } from 'react';

export default function CheckoutButton() {
  const [, set] = useState(false);

  const startCheckout = async () => {
    set(true);
    const res = await fetch('/api/stripe/checkout', { method: 'POST' });
    // handle response...
    set(false);
  };

  return <button onClick={startCheckout} disabled={}>Buy</button>;
}

NEXT_PUBLIC_

prefixes for real secrets If you have already renamed a secret, revert the name in the source and run a clean build:

- const stripeKey = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;
+ const stripeKey = process.env.STRIPE_SECRET_KEY; // server‑only

Run a free KeyDrift scan (read‑only, no credentials) after the change:

npx keydrift scan --path ./out

The scan should no longer report the secret in the client bundle.

KeyDrift provides a concrete, read‑only audit that surfaces these leaks before they reach production. By moving secret usage back to server‑only code and avoiding the NEXT_PUBLIC_

prefix for real credentials, you eliminate the most common source of client‑bundle secret exposure in Next.js projects.

For more detailed guidance see the KeyDrift Fix Guides on “exposed keys by tool and credential.”