Is your v0 app secure? A security checklist for v0 and Vercel

v0 turns a prompt into Next.js and React code, usually with shadcn/ui, and deploys it to Vercel. The interface looks finished from the first prompt. What v0 cannot see is how your keys, database rules and endpoints are set up once the app is live, so that part is yours to check.

Is a v0 app secure by default?

v0 generates standard Next.js code, so it inherits the framework's defaults: no Content-Security-Policy or HSTS, and every route handler and server action is a public endpoint. A v0 app is as secure as the keys, auth checks and database rules you add, so review those before you share the link.

Common security risks in v0 apps

  1. 1. Secret keys behind NEXT_PUBLIC_ variables

    Anything prefixed NEXT_PUBLIC_ is inlined into the JavaScript every visitor downloads. A secret stored that way is public, even if no page displays it. Keep secrets in unprefixed variables that only server code reads.

  2. 2. Server actions and route handlers without auth checks

    Each server action and route handler can be called directly, without your UI. Verify the session and the user's permission inside every one, not just in the page that renders the button.

  3. 3. Database integrations without row-level rules

    Integrations add connection strings or keys as environment variables. Keep them server-side. If the browser talks to Supabase directly, Row Level Security has to protect every table, and a service_role or sb_secret_ key must never reach client code.

  4. 4. AI features that anyone can call

    A chat or image feature that calls a model provider from a route handler, with no login and no rate limit, lets anyone spend your credits.

  5. 5. No security headers

    Without a Content-Security-Policy, HSTS and anti-clickjacking headers, an injected script or a framing page has an easier job. Add them in next.config or proxy.ts.

What a FixPrompt scan checks

Passive checks on your public site, the same way a visitor's browser loads it. No attacks, no logins, no data queried.

  • Secret key patterns in the client bundle, including values that leaked through public env vars
  • Content-Security-Policy strength, HSTS (age and subdomains), X-Frame-Options / frame-ancestors, nosniff, Referrer-Policy and Permissions-Policy
  • Supabase service_role JWTs and sb_secret_ keys in JavaScript bundles
  • API paths that answer anonymous requests and missing rate-limit headers
  • Public source maps, .env files and .git folders
  • Session cookie flags and caching headers on login pages

Copy-paste fix prompt

Paste this into Claude Code, Cursor, Codex or any coding agent with access to your repository. A scan gives you a prompt tailored to the issues found on your live site.

Fix prompt

Audit this v0 / Next.js project for security issues and fix them in priority order:

1. List every NEXT_PUBLIC_ environment variable. Move any secret to a server-only variable, use it only in server code, and tell me which keys to rotate.
2. In every route handler and server action, verify the session and the user's permission before reading or changing data.
3. If the app uses Supabase from the browser, make sure Row Level Security is on for every table with owner-based policies, and that no service_role or sb_secret_ key is in client code.
4. Add authentication and rate limiting to any route that calls a paid AI or email API.
5. Add security headers in next.config or proxy.ts: a Content-Security-Policy without unsafe-inline or unsafe-eval for scripts, Strict-Transport-Security, frame-ancestors 'none', X-Content-Type-Options: nosniff and Referrer-Policy.

Explain each change and how to verify it.

Want rules your agent follows on every task? Get security rules for Cursor, CLAUDE.md and AGENTS.md.

FAQ

Does v0 add security headers?
Not by default. Next.js sends no Content-Security-Policy or HSTS, so add them with the headers option in next.config, or in proxy.ts (middleware.ts before Next.js 16) if you want a nonce-based CSP.
Are environment variables in a v0 project safe?
Variables without the NEXT_PUBLIC_ prefix stay on the server. Those with the prefix are bundled into the front end, so use that prefix only for values designed to be public, such as an analytics ID or a Supabase anon key.
Can I scan a v0 app before I share it?
Yes. Paste the deployed URL and FixPrompt checks the public site passively, then gives you a prompt your coding agent can apply. It never attacks the app or tries credentials.

Check your v0 app in minutes

Paste your URL and get a plain-English report with prioritized risks and a fix prompt for your AI. Your first scan is free.

Scan my app free