How to Deploy v0 Apps Securely (2026)

v0-generated Next.js apps have a consistent pre-deploy security problem: the code works perfectly in development but leaks secrets the moment you push to production. In our scans of Next.js apps built with v0, the most common issue is NEXT_PUBLIC_-prefixed API keys baked into the client bundle. Every visitor to the deployed site can read those keys from the page source. The fix is straightforward, but you have to do it before you deploy, not after.

This guide covers the six steps to go from a v0 project to a production-ready Next.js app without the common leaks.

Step 1: Audit NEXT_PUBLIC_ Prefixes

This is the highest-ROI step. Run one command before you do anything else.

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

1. Open your deployed v0 app in Chrome
2. Press F12 → Sources tab
3. Press Ctrl+Shift+F (search across files)
4. Search for "sk_proj_" or "OPENAI" or "STRIPE"
5. If you see your key in a .js file, it is in the bundle

Step 2: Move Secret API Calls Server-Side

v0 puts API calls in React components because that is the path of least resistance. These components run in the browser. You need to move the secret-touching code to the server.

Option A: Route Handlers (recommended for most cases)

Route Handlers live in app/api/ and run only on the server. Your React component calls your Route Handler via fetch, and the Route Handler calls the third-party API. The secret never reaches the browser.

Before (v0-generated, secret in client bundle):

// app/components/ChatWidget.tsx
"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 }] }),
    });
  };
}

After (secret stays on server):

// app/api/chat/route.ts
import OpenAI from "openai";

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

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
"use client";

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

Option B: Server Actions (cleaner for form submissions)

If your v0 app uses form inputs that trigger AI or payment calls, Server Actions are a cleaner pattern:

// 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;
}

The "use server" directive ensures this module only runs on the server, even if imported in a client component.

Step 3: Configure Vercel Environment Variables

Vercel injects environment variables at build time (for NEXT_PUBLIC_ variables) or at runtime (for everything else). Your secrets need to be runtime-only.

Step 4: Add Security Headers

Security headers stop several common attack classes: clickjacking, cross-site scripting, content sniffing. A fresh v0 project ships with none of them.

Add headers in next.config.js:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          { key: "X-Content-Type-Options", value: "nosniff" },
          { key: "X-Frame-Options", value: "DENY" },
          { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
          {
            key: "Permissions-Policy",
            value: "camera=(), microphone=(), geolocation=()",
          },
          {
            key: "Content-Security-Policy",
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline' 'unsafe-eval'", // tighten after testing
              "style-src 'self' 'unsafe-inline'",
              "img-src 'self' data: https:",
              "connect-src 'self' https://api.openai.com", // add your own API domains
            ].join("; "),
          },
        ],
      },
    ];
  },
};

module.exports = nextConfig;

Start with this and tighten the CSP after you've verified your app works. unsafe-inline and unsafe-eval are intentionally included for initial setup because v0-generated apps often use inline styles and dynamic evaluation. Remove them once you've confirmed your app works without them.

Step 5: Protect Preview Deployments

Every push to your repo triggers a preview deployment at a URL like your-project-abc123.vercel.app. Anyone with that URL can access your app. By default, Vercel does not require authentication to view it.

Step 6: Check Supabase RLS (if you are using Supabase)

v0 apps frequently connect to Supabase for data persistence. The Supabase anon key is public by design, but it only stays safe if Row Level Security is enabled on every table. Without RLS, the anon key gives anyone full read and write access to your database.

-- Run this in Supabase SQL Editor to check which tables have RLS disabled
SELECT
  schemaname,
  tablename,
  rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY tablename;

Any row with rowsecurity = false is exposed. For tables that should be private, enable RLS and add policies:

-- Enable RLS on a table
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Basic policy: users can only see their own rows
CREATE POLICY "Users see own rows"
ON your_table
FOR ALL
USING (auth.uid() = user_id);

If v0 generated a Supabase client using NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY (the service_role key bypasses RLS entirely), treat it as a critical issue. The service_role key must never be in a client component. Move it to a Route Handler.