v0 security checklist: The Next.js + Supabase security checklist for v0-generated apps.

A v0 security checklist covers the entire backend security layer that v0 by Vercel does not generate: authentication middleware, API route protection, server action authorization, Supabase RLS policies, input validation, and rate limiting. Adding auth checks to every API route and enabling RLS on all Supabase tables are the two highest-impact fixes before launching any v0-built app. v0 produces fast, polished frontend code — but authentication, authorization, and database access controls are not part of its output, and every API route it creates is publicly callable by anyone who discovers the URL.

Key Security Risks in v0-Generated Apps

Unprotected API routes by default: v0 generates Next.js API routes and server actions without authentication middleware. Every route it creates is publicly callable by anyone who discovers the URL — no login required.

Service role key in shared utilities: When founders wire up Supabase quickly, the service role key frequently ends up in a shared lib/supabase.ts file imported by both client and server components. That key bypasses all RLS policies for anyone who loads the page.

Missing RLS on Supabase tables: v0 generates frontend queries to Supabase, but does not create RLS policies. Tables without policies are readable by any authenticated or anonymous user with the anon key.

Serverless endpoints without rate limits: Vercel Edge and serverless functions have no built-in rate limiting. An unthrottled AI route or data export endpoint is an open invitation to abuse.

No input validation on generated forms: v0 form handlers process submissions without schema validation by default. Without validation, write endpoints accept arbitrary data including oversized payloads and injected fields.

Authentication Setup

v0 does not add auth. You must add it explicitly before going to production.

• Add authentication with NextAuth.js, Clerk, or Supabase Auth before exposing any user-facing routes.
• Create a middleware.ts file in your Next.js root to protect all private routes at the edge.
• Protect every API route handler and server action with a session check at the top of the function.
• Test direct API access with missing tokens, expired tokens, and forged session values.

// middleware.ts — protect all /dashboard routes
import { withAuth } from 'next-auth/middleware';
export default withAuth({
  pages: { signIn: '/login' }
});
export const config = {
  matcher: ['/dashboard/:path*', '/api/user/:path*', '/api/data/:path*']
};

Secrets & Service Role Key

• Keep SUPABASE_SERVICE_ROLE_KEY in server-only environment variables — never prefixed with NEXT_PUBLIC_.
• Never import the service role client in files that are also used by client components.
• Scan your Next.js bundle for service role key strings before every production deploy.
• Rotate any key that appeared in a client bundle, a preview deployment, or a Vercel log.

// Wrong — service role accessible from client
// lib/supabase.ts (imported by both client and server components)
export const supabaseAdmin = createClient(url, process.env.SUPABASE_SERVICE_ROLE_KEY!);

// Correct — separate server-only client
// lib/supabase-server.ts (only imported in server components and API routes)
import 'server-only';
export const supabaseAdmin = createClient(url, process.env.SUPABASE_SERVICE_ROLE_KEY!);

Supabase RLS & Database Security

• Enable RLS on all Supabase tables containing user or tenant data.
• Validate every RLS policy with negative tests: verify that denied requests are actually blocked.
• Restrict storage bucket access and signed URL generation to the authenticated owner.
• Confirm background jobs and cron routes use scoped service permissions, not admin access.
• Test cross-user data access by querying with a valid session for a different user's resource ID.

-- Test your RLS policy is working
-- 1. Get user B's record ID
-- 2. Query as user A using user A's JWT
-- 3. Expect 0 rows returned, not an error and not user B's data

select * from documents where id = 'user-b-doc-id';
-- Should return 0 rows when authenticated as user A

Input Validation on All Write Endpoints

• Validate every request body with Zod or Valibot before inserting into the database.
• Reject unknown fields — v0-generated handlers often spread request body directly into inserts.
• Add maximum length limits on all string inputs to prevent oversized payload abuse.
• Test that malformed, oversized, and injected payloads are rejected with a 400 response.

// v0 often generates this pattern — no validation
export async function POST(req: Request) {
  const body = await req.json();
  await supabase.from('posts').insert(body); // ← accepts anything
}

// What you need
const PostSchema = z.object({
  title: z.string().min(1).max(200),
  content: z.string().min(1).max(10000),
});
export async function POST(req: Request) {
  const session = await auth(); // auth check first
  if (!session) return new Response('Unauthorized', { status: 401 });
  const body = PostSchema.parse(await req.json());
  await supabase.from('posts').insert({ ...body, userId: session.user.id });
}

Rate Limiting Vercel Endpoints

• Use Upstash Redis or Vercel KV for distributed rate limiting on Edge and serverless functions.
• Apply per-IP and per-user limits on auth, mutation, and AI proxy routes.
• Monitor and alert on sustained 429 bursts — these indicate active abuse.

// Rate limiting with Upstash on a Vercel API route
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';
const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(20, '1 m'),
});
const ip = request.headers.get('x-forwarded-for') ?? 'anonymous';
const { success } = await ratelimit.limit(ip);
if (!success) return new Response('Too Many Requests', { status: 429 });

CORS & API Hardening

• Set explicit origin allowlists for API routes — never wildcard in production.
• Remove wildcard CORS from any route that handles authenticated or paid operations.
• Limit allowed HTTP methods per route to the minimum required.
• Return generic error messages in production — never expose stack traces or internal details.

Related Security Checklists

v0 apps commonly use Supabase and deploy to Vercel. After completing this checklist, review the Supabase security checklist for database-layer policy validation. For a full pre-launch security sweep covering every AI tool pattern, use the pre-deploy security checklist for vibe-coded apps.

Run Your Security Audit

Want to know which v0 by Vercel security gaps exist in your current codebase?

Ubserve scans your Next.js app for unprotected routes, exposed service-role keys, missing RLS, weak CORS, and every pattern on this checklist. Every finding includes a fix prompt you paste directly into v0 or your code editor to resolve it before launch.

Audit my v0 app for these vulnerabilities

A polished v0 UI with a broken backend is not a secure app. The frontend is the last thing an attacker looks at.

Run the audit. Fix what it flags. Ship with confidence.

— Mr. Ballaz, Founder of Ubserve