Is My v0 App Secure? A Plain-English Next.js Security Checklist (2026)

v0 by Vercel builds Next.js apps and deploys them to Vercel in a few clicks. Next.js is a mature framework with good security tools. But generated code still has to use those tools correctly, and some of the most important checks are easy to leave out.

This checklist is written for founders, not security experts. Each item explains what to look for in a v0 app and why it matters.

1. How a v0 app is put together

A v0 app is a Next.js app. Some of its code runs in your visitors' browsers and some runs on Vercel's servers: pages rendered on the server, route handlers (your API) and Server Actions (functions the browser can call). Data usually lives in a connected database such as Supabase or Neon, which v0 integrates with.

The key question for every piece of code is: does it run on the server or in the browser? Anything in the browser can be read and changed by anyone.

2. Secret keys and `NEXT_PUBLIC_`

Next.js's docs explain the rule: "By default, environment variables are only available on the server. To expose an environment variable to the browser, it must be prefixed with NEXT_PUBLIC_."

• List every NEXT_PUBLIC_ variable. Each one is public. A Stripe secret key, an AI provider key or a database admin key must never have that prefix. v0's security docs say the same: "Never expose sensitive tokens with NEXT_PUBLIC_ prefix".
• Store secrets in Vercel's environment variables, and use the Secret type for the most sensitive ones: Vercel says Secret values "are write-only after saving".
• If the project syncs to GitHub, check that no .env file or key was ever committed. If a secret was ever exposed, rotate it.

3. Server Actions and API routes check the user

This is the most common gap in Next.js apps. Next.js's authentication guide says: "Treat Server Actions with the same security considerations as public-facing API endpoints, and verify if the user is allowed to perform a mutation." The same applies to route handlers.

• Every Server Action and route handler checks the session itself. Next.js's data security guide warns that "a page-level authentication check does not extend to the Server Actions defined within it."
• Don't rely only on proxy (formerly called middleware) for protection. Next.js says it "should not be your only line of defense in protecting your data."
• Check authorization, not just login: is this user allowed to read or change this specific record?
• Admin features check the role on the server, not just in the page layout.

Why the warning about middleware? In 2025, a vulnerability (CVE-2025-29927) let attackers skip Next.js middleware on self-hosted apps. Vercel's postmortem says apps hosted on Vercel weren't vulnerable, and fixed versions were released (Next.js 14.2.25 and 15.2.3). Its advice still holds for everyone: "We do not recommend Middleware to be the sole method of protecting routes in your application." Keep Next.js up to date.

4. Database rules

• If your app uses Supabase from the browser, Row Level Security must be on for every table, with rules that limit each user to their own rows. Supabase's docs: "Enable RLS on every table in an exposed schema."
• If your app reaches the database only from server code, each query must filter by the logged-in user.
• Do the two-account test. Sign in as user A and create something. Sign in as user B in another browser and try to see or change it.

5. Deployments and headers

• Know what's public. Vercel's Standard Deployment Protection "protects all deployments except production domains". Your production site is public, which is what you want, so anything unfinished must be protected by your own login.
• Add security headers (HSTS, a Content-Security-Policy or frame-ancestors, X-Content-Type-Options: nosniff) with headers() in your Next.js config. Next.js's headers docs have examples.
• Run npm audit for known-vulnerable packages.

6. Payments and abuse

• Stripe webhooks verify the signature (Stripe's docs), and prices and paid features are checked on the server.
• Rate limits on sign-up, login and AI calls, so one script can't run up your bill.

7. What v0 does for you

v0's security docs say it "analyzes NEXT_PUBLIC_ usage and warns users about potential security risks". Take those warnings seriously. When v0 is connected to GitHub, it opens a pull request for its changes instead of pushing straight to your base branch, which gives you a natural moment to review what changed, especially in auth and data code.

What no tool can know is your business rules: who should see which records, and which actions need which role. That's what the server-side checks and the two-account test are for.

8. Where to start

If you only have an hour: list your NEXT_PUBLIC_ variables, open every Server Action and route handler and confirm each one checks the user, and do the two-account test.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with v0. A free mini scan checks five high-impact items, including exposed keys and open database tables. A full audit covers 25 checks, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.