How to Secure Your v0 App Before Production

v0 is remarkable for prototyping. You describe a UI, it generates a working Next.js app with Tailwind and shadcn/ui, and you can deploy to Vercel in minutes. We use it ourselves for internal tools. But the gap between "working prototype" and "production-ready application" is almost entirely security — and v0 doesn't bridge that gap for you.

This guide covers the specific hardening steps we recommend after generating a v0 app and before putting real user data behind it.

Step 1: Audit Your Environment Variables

Open your .env.local file and categorize every variable:

• Server-only secrets: database URLs, API secret keys, JWT signing keys, SMTP credentials
• Client-safe values: public API endpoints, feature flags, analytics IDs

Any variable that v0 prefixed with NEXT_PUBLIC_ needs to be checked. If it's a secret, remove the prefix and access it only in server components, server actions, or route handlers.

# Check what's in your client bundle
npx next build
grep -r "NEXT_PUBLIC" .next/static -l
# Review each file — if a secret appears, you have a leak

Step 2: Add Authentication to Every Mutation

v0 often generates admin interfaces and CRUD operations with no auth. Search your codebase for every 'use server' directive and every Route Handler (route.ts files):

# Find all server actions and route handlers
grep -rn '"use server"' src/
find src -name "route.ts" -o -name "route.js"

For each one, verify there's a session check at the top of the function. If you're using NextAuth v5:

import { auth } from "@/server/auth";

export async function myServerAction() {
  const session = await auth();
  if (!session?.user) {
    throw new Error("Unauthorized");
  }
  // ... rest of the action
}

Step 3: Add Input Validation with Zod

v0 generates forms with client-side validation via HTML attributes. That's a UX feature, not a security control. Every server action and route handler needs server-side validation:

import { z } from "zod";

const CreateProjectSchema = z.object({
  name: z.string().min(1).max(100),
  description: z.string().max(500).optional(),
  isPublic: z.boolean().default(false),
});

export async function createProject(formData: FormData) {
  "use server";
  const session = await auth();
  if (!session?.user) throw new Error("Unauthorized");

  const parsed = CreateProjectSchema.safeParse({
    name: formData.get("name"),
    description: formData.get("description"),
    isPublic: formData.get("isPublic") === "true",
  });

  if (!parsed.success) {
    return { error: parsed.error.flatten() };
  }
  // ... create with parsed.data
}

Step 4: Configure Security Headers

Add a headers configuration to your next.config.js. At minimum:

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          { key: "X-Content-Type-Options", value: "nosniff" },
          { key: "X-Frame-Options", value: "DENY" },
          { key: "Strict-Transport-Security", value: "max-age=31536000; includeSubDomains" },
          { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
          { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()" },
        ],
      },
    ];
  },
};

Content-Security-Policy is harder to configure correctly with Next.js's inline scripts, but even a report-only CSP gives you visibility into what's running on your pages.

Step 5: Lock Down Database Access

If v0 generated Prisma queries, check for:

• Raw queries ($queryRaw, $queryRawUnsafe) — replace with parameterized versions
• Missing where clauses that scope data to the current user's organization
• Overly broad select statements that return sensitive fields to the client

// Before: returns everything including password hash
const user = await prisma.user.findUnique({ where: { id } });

// After: select only what the client needs
const user = await prisma.user.findUnique({
  where: { id },
  select: { id: true, name: true, email: true, avatar: true },
});

Step 6: Add Rate Limiting

Install a rate limiting package and apply it to authentication and mutation endpoints. For Next.js middleware:

// Using @upstash/ratelimit with Redis
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "1 m"), // 10 requests per minute
});

export async function POST(req: Request) {
  const ip = req.headers.get("x-forwarded-for") ?? "127.0.0.1";
  const { success, remaining } = await ratelimit.limit(ip);
  if (!success) {
    return Response.json({ error: "Rate limited" }, { status: 429 });
  }
  // ... handle request
}

Step 7: Configure Vercel Deployment Securely

Before deploying:

• Enable Vercel's DDoS protection (automatic on Pro plans)
• Set environment variables in the Vercel dashboard — never commit .env files
• Enable Vercel's built-in firewall rules for known attack patterns
• Restrict preview deployments with Vercel Authentication if your app handles sensitive data
• Set up deployment protection to require approval for production deployments

Step 8: Run an Automated Security Scan

After completing steps 1-7, scan your deployed app. Not your source code — your running application. Source code analysis misses runtime configuration issues, deployment misconfigurations, and interaction-dependent vulnerabilities.

A security scan against your live deployment catches what code review misses: misconfigured CORS, exposed debug endpoints, missing headers on specific routes, and auth bypass chains that only manifest in the deployed environment.

Run a scan every time you deploy. Make it part of your CI pipeline. The seven steps above handle the predictable issues. An automated scan catches everything else.