v0 hardcoded an API key — how to fix it

If v0 generated code with an API key inline, rotate that key first, then move it to an environment variable, and make sure it is only used server-side. A key in a Next.js client component ships to the browser and is public no matter how you store it, so where the key is used matters as much as where it is stored.

Why it's a problem

Two problems stack here. First, a hardcoded key in committed source is exposed to anyone with the repo. Second, v0 often generates client components, and any secret referenced in client code is bundled and shipped to the browser, where it is readable by every visitor. Storing it in an environment variable does not help if it is still read from the client.

How to fix it, in order

1. 1Rotate the key. Revoke and regenerate it at the provider before anything else, because the exposed value is already out.
2. 2Move the call server-side. Any secret key must be used in a server component, route handler, or server action, never in a client component. Fetch data on the server and pass only the result to the client.
3. 3Read it from the environment. Store the key in .env.local (gitignored) and read it via process.env on the server. Do not prefix a secret with NEXT_PUBLIC_, which exposes it to the browser.
4. 4Purge it from history if committed. Use filter-repo or BFG and force-push, remembering the rotation in step one is what actually protects you.

Why v0 does this

v0 produces polished UI code fast, and when an integration needs a key, inlining it is the path that makes the generated component render. It does not distinguish a public key from a secret one, or reason about whether the component runs on the server or the client, because that is a judgment about your app rather than the code.

Stop it happening again

In Next.js, keep secrets in server-only code and never behind a NEXT_PUBLIC_ prefix. Store them in a gitignored .env.local, and add a gitleaks pre-commit hook so an inline key fails the commit.

The quick fix

• Rotate the key first.
• Use the key only in server components or route handlers, never client code.
• Read it from process.env server-side; never use a NEXT_PUBLIC_ prefix for a secret.
• Purge from git history if committed and add a pre-commit secret scanner.