Your v0 app looks finished. Looking finished isn’t launched.

Next.js App Router · shadcn/ui · Vercel hosting · by the team that makes AI-built apps bulletproof

The 8 risks real v0 apps ship with

Compiled from documented incidents, CVEs, and platform docs — the same failure modes a Launch Check hunts for in your app, with what to do about each.

1. Secrets shipped to the browser via NEXT_PUBLIC_

   The only way a client component can read an env var in Next.js is the NEXT_PUBLIC_ prefix — which embeds the value in the public bundle. v0 builds UI-first, so keys pasted to make a preview work land client-side constantly: Vercel blocked 17,000+ deployments in one month for exposed Supabase, OpenAI, Google Maps, and PostHog keys. Keys that shipped in earlier deploys stay live even after the scanner starts catching new ones.

   What to do: Grep the codebase for NEXT_PUBLIC_ and “use client” files touching credentials; move sensitive calls into Server Actions or route handlers. Assume any key that ever appeared client-side or in the synced GitHub repo is compromised — rotate it and redeploy.

2. Server Actions with zero authentication

   v0 uses Server Actions for mutations, and a Server Action is a public HTTP endpoint — anyone can invoke it with a crafted POST, no UI required. Because v0 generates the form and the action together and the demo “just works,” the missing auth check is invisible in testing. One scanner reports effectively 0% of analyzed v0 apps had proper guards inside their Server Actions.

   What to do: Treat every Server Action like a public API route: the first line validates the session and role, before any database work. Add a shared withAuth() wrapper so future generations can’t ship an unguarded action. Test by invoking the action with curl while logged out.

3. Mock data and stub handlers that survive into production

   v0 hardcodes sample content because the preview has to render something — dashboards, tables, and flows powered by baked-in arrays and no-op submits. Builders report the same arc: screens look finished, then in production half the features turn out to be wired to nothing.

   What to do: Do a data-wiring audit before launch: grep for hardcoded arrays, TODO stubs, and fetches pointing at mock endpoints. Then smoke-test the 3–5 critical paths — signup, login, the core action, payment — against the production database, not the v0 preview.

4. IDOR in dynamic routes — any user can read anyone’s data

   Generated handlers like /api/orders/[id] fetch by the id in the URL without checking the session user owns that record. The UI only ever links to your own ids, so the hole never appears in normal use — but changing the number in the URL exposes every other user’s data. Scanners list this among the most common v0 findings.

   What to do: Scope every query by the authenticated user (…AND user_id = sessionUserId) or verify ownership before returning. Audit every [param] route and id-taking Server Action. Test with two accounts: as user A, request user B’s resource ids.

5. Bolted-on Supabase with Row Level Security off

   v0’s one-click integrations get data flowing fast, but tables created via SQL have RLS off by default and the anon key legitimately ships in your bundle. The identical stack pattern produced CVE-2025-48757 at Lovable — 303 endpoints readable by unauthenticated requests. v0 + Supabase inherits the same default.

   What to do: Enable RLS on every public-schema table and write per-table policies (RLS with no policies breaks the app, which tempts people toward the service-role key client-side — worse). Verify by querying the REST endpoint with only the anon key, logged out.

6. No rate limiting — abuse, credential stuffing, runaway bills

   v0 generates signup flows, contact forms, and AI endpoints with no throttling. Vercel’s platform blocks volumetric DDoS but does not rate-limit your application logic: a script hitting your AI endpoint 10,000 times is “legitimate” traffic that burns your OpenAI credits. On Hobby, hitting limits pauses your deployment — downtime; on Pro it’s a surprise bill.

   What to do: Add @upstash/ratelimit (Redis is one click in v0’s own integrations) or Vercel WAF rules on auth, form, and AI endpoints. Set Vercel Spend Management alerts with an auto-pause threshold, and cap per-user usage of AI features in the database.

7. Middleware as the only auth gate

   v0 apps commonly centralize auth in middleware.ts — and Next.js middleware has already had a critical bypass (CVE-2025-29927, CVSS 9.1: a header that skipped middleware entirely). Projects synced to GitHub can pin vulnerable Next.js versions long after the patch. Vercel’s own guidance: middleware is optimistic routing, not the security boundary.

   What to do: Re-check the session at the data layer — Server Actions, route handlers, queries — not just in middleware. Keep Next.js current in the synced repo (Dependabot on the GitHub sync), and allowlist any redirect destinations middleware constructs from URL params.

8. No tests, no monitoring, and platform limits discovered in production

   v0 outputs zero tests and no observability — the first real error report is a user screenshot. Meanwhile Vercel abstracts servers but not workloads: Hobby cron runs at most daily, functions default to short timeouts, and there are no built-in background workers — so long imports, email batches, and webhooks time out silently.

   What to do: Wire Sentry via the Vercel integration before launch and write smoke tests for the flows v0 generated. Move anything longer than a request — exports, batch jobs, email runs — to a queue (Inngest, QStash, trigger.dev) instead of stretching function timeouts.

Common questions