How to Fix v0 API Key Exposure (2026)

A v0-generated Next.js app with an exposed OpenAI key can drain your credits in hours. In our scans of Next.js projects deployed on Vercel, the single most common secret exposure pattern is a NEXT_PUBLIC_OPENAI_API_KEY variable that Next.js silently baked into the client JavaScript bundle at build time. The NEXT_PUBLIC_ prefix is Next.js's way of making values available to browser code, and it works exactly as advertised, including for secrets you did not intend to share.

This guide walks you through finding the leak, rotating the key, and fixing the root cause so it does not happen again.

Why v0 Apps Have This Problem

v0 started as a UI component generator, but it has grown into a full Next.js app builder. When you ask it to add AI features, payment processing, or data fetching, it generates code that calls third-party APIs. That generated code often uses environment variables with the wrong prefix.

v0 generates NEXT_PUBLIC_ variables because they work. When v0 adds an OpenAI integration, it may produce process.env.NEXT_PUBLIC_OPENAI_API_KEY because this makes the variable accessible to the React component. The code runs correctly in development. In production, that key is also accessible to every person who visits your site.

v0 targets Vercel deployments. Unlike Bolt.new (which targets Netlify) or Replit (which runs its own servers), v0 apps are built for Vercel and use the Next.js App Router or Pages Router. The fix involves Vercel environment variables and Next.js Route Handlers or Server Actions, not Netlify Functions or Replit Secrets.

Step 1: Find the Exposed Key

Before rotating, confirm exactly what is exposed and how.

# In your v0 project root
grep -r "NEXT_PUBLIC_" . \
  --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env*" \
  --exclude-dir=node_modules --exclude-dir=.next

# Also check .env.local for the prefix
grep "NEXT_PUBLIC_" .env.local 2>/dev/null

grep -r "service_role\|SERVICE_ROLE" . \
  --include="*.ts" --include="*.tsx" --include="*.js" \
  --exclude-dir=node_modules

git log --all --full-history -- .env.local
git log --all --full-history -- .env.production
git log --all --full-history -- .env

Step 2: Rotate the Exposed Key Immediately

Do not try to fix the code first. The key is already out. Rotate it now.

Step 3: Remove from Git History (if committed)

If your audit found secrets in git history, scrub them from every commit.

# Install git-filter-repo
pip install git-filter-repo

# Remove .env.local from all history
git filter-repo --path .env.local --invert-paths
git filter-repo --path .env.production --invert-paths
git filter-repo --path .env --invert-paths

After scrubbing, force-push to all remotes and notify any collaborators to re-clone. If the repo was public at any point, treat the key as compromised regardless of whether you can confirm it was accessed.

Add all .env variants to .gitignore:

echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.*.local" >> .gitignore
echo ".env.production" >> .gitignore
git add .gitignore && git commit -m "chore: gitignore .env files"

Step 4: Fix the Root Cause (NEXT_PUBLIC_ Prefix)

Rotating fixes the immediate risk. Fixing the root cause stops it from happening again on the next deploy.

Why NEXT_PUBLIC_ Variables Are Dangerous

Next.js embeds every variable prefixed with NEXT_PUBLIC_ into the client bundle at build time. The prefix is designed to share configuration values with browser code: public API base URLs, feature flags, analytics IDs. Using it with a secret key is the wrong tool for the job.

Wrong (key ends up in every visitor's browser):

// app/components/ChatWidget.tsx - generated by v0
"use client";

export function ChatWidget() {
  const handleSubmit = async (message: string) => {
    const res = await fetch("https://api.openai.com/v1/chat/completions", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.NEXT_PUBLIC_OPENAI_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ model: "gpt-4o", messages: [{ role: "user", content: message }] }),
    });
    // ...
  };
}

Right (API call moved to a Route Handler, key stays server-side):

// app/api/chat/route.ts - server-side only, key never reaches browser
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export async function POST(req: Request) {
  const { message } = await req.json();
  const response = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: message }],
  });
  return Response.json({ reply: response.choices[0].message.content });
}

// app/components/ChatWidget.tsx - client component calls YOUR route, not OpenAI directly
"use client";

export function ChatWidget() {
  const handleSubmit = async (message: string) => {
    const res = await fetch("/api/chat", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ message }),
    });
    const data = await res.json();
    // ...
  };
}

Your React component calls /api/chat on your own domain. Your Route Handler calls OpenAI. The key never reaches the browser.

Alternative: Server Actions

If you prefer Server Actions over Route Handlers, mark the action with "use server" and the key stays on the server automatically:

// app/actions/chat.ts
"use server";
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export async function generateReply(message: string) {
  const response = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: message }],
  });
  return response.choices[0].message.content;
}

Variable Naming in Vercel

In Vercel's environment variables panel, name your secret without any public prefix:

Then access it in your Route Handler as process.env.OPENAI_API_KEY. Vercel injects it only at runtime, only into server-side code.

Step 5: Fix Supabase service_role Misuse

The Supabase service_role key bypasses every Row Level Security policy in your database. It is designed for server-side admin operations only.

v0 occasionally generates a Supabase client in a component or hook that uses the service_role key directly. Any visitor who opens DevTools has full read and write access to your entire database.

Wrong (service_role in a client component):

// app/components/DataTable.tsx - generated by v0
"use client";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // never do this
);

Right (anon key client-side, service_role only in Route Handlers):

// app/components/DataTable.tsx - anon key, controlled by RLS
"use client";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // public by design
);

// app/api/admin/route.ts - service_role only here, server-side
import { createClient } from "@supabase/supabase-js";

const adminClient = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // no NEXT_PUBLIC_ prefix = server-only
);

The anon key is safe to expose because Supabase RLS policies control what it can access. Enable RLS on every table and add policies that match your auth model.

Step 6: Prevent Future Leaks

Pre-commit Hook with Gitleaks

Gitleaks scans for secrets before each commit:

# Install gitleaks (macOS)
brew install gitleaks

# Test your current repo
gitleaks detect --source . --verbose

# Add a pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "Gitleaks found potential secrets. Commit blocked."
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

What to Put Where