Which environment variables are safe to use in a v0 Next.js app?

In Next.js, only variables prefixed NEXT_PUBLIC_ are sent to the browser, and everything with that prefix is public. Server-only secrets must not carry the prefix so they stay on the server. Check that no payment key, database URL, or admin token was given a NEXT_PUBLIC_ prefix by mistake.

Do v0 Server Actions check authentication on their own?

No. A Server Action or route handler in a v0-generated app is a public endpoint that runs whatever code it contains. If it does not check the session and the caller's permissions itself, anyone can invoke it directly, regardless of what the UI shows. Every mutating action needs its own auth check on the server.

Is a v0 app secure because the code runs on the server?

Running on the server prevents secrets from leaking into the browser, but it does not make endpoints private. Server Actions and route handlers are still reachable over the network. Security comes from each of them verifying the session and authorizing the specific record being touched, not from where the code executes.

How to test a v0 app before your users do

v0 turns a prompt into a polished Next.js app with real server code. The polish is genuine — which is exactly why it's easy to assume the security is handled too. It usually isn't. Here's the v0-specific check to run before you ship.

What v0 actually gives you

A v0 project is a Next.js app — the App Router, React Server Components, shadcn/ui, and usually Server Actions or route handlers for anything that writes data, deployed to Vercel. Unlike a pure client app, real code runs on the server, which is good: secrets can stay off the browser. But Server Actions and route handlers are still public network endpoints. v0 wires up the happy path and the pretty UI; it does not reliably add the "is this person allowed to do this?" check to each endpoint. These eight checks target that.

The v0 pre-launch checklist

1. Audit your NEXT_PUBLIC_ variables

In Next.js, only variables prefixed NEXT_PUBLIC_ reach the browser — and everything with that prefix does. Open your .env and your Vercel project settings and confirm no secret (payment key, database URL, admin token) was given the NEXT_PUBLIC_ prefix. Then search the browser bundle for sk_ and SECRET to be sure nothing leaked another way.

2. Call your Server Actions and route handlers while signed out

This is the big one. In dev tools → Network, find the POST requests your app makes when you save or submit something. Replay one from a signed-out session. A v0 Server Action runs its code whether or not you're logged in unless it checks the session itself. If a signed-out request succeeds, anyone can write to your database directly.

3. Try to act on another user's records

Sign up two accounts. As account A, note a record ID. As account B, call the update or delete endpoint for A's ID. Even apps that check "are you logged in?" often forget to check "is this your record?" — that gap is IDOR, and it lets any logged-in user edit anyone's data.

4. Make a stranger sign up

Register in a private window. Does verification actually work end to end? v0 frequently scaffolds auth UI (often with NextAuth/Auth.js) but leaves the wiring incomplete — a login form that looks real but doesn't enforce anything. Confirm a wrong password is rejected and an unverified account can't reach protected pages.

5. Feed every form hostile input

Paste 2,000 characters, emoji, an apostrophe, and <img src=x onerror=alert(1)> into each field. React escapes output by default, so the payload should render as literal text — unless the code uses dangerouslySetInnerHTML. Confirm nothing crashes the server render, either.

6. Follow every button, and check protected pages directly

Walk checkout, billing, and account flows to the end. Then, while signed out, type a protected URL (like /dashboard) straight into the address bar. If the page renders instead of redirecting to login, your route protection is missing — middleware or a per-page session check wasn't added.

7. Use it on a phone and refresh mid-flow

Shrink to 375px or open on your phone. v0's shadcn/ui components are responsive by default, but custom layouts drift — check for overflow and tappable targets. Refresh in the middle of a multi-step flow to confirm it recovers.

8. Can a user delete their account?

Sign up and try to delete everything. GDPR's Right to Erasure requires a real delete path, and v0 rarely generates one. Confirm the delete removes the user's rows, not just their session. (See our GDPR checklist.)

If you do only one thing: replay one of your Server Actions from a signed-out session. If it succeeds, your database is writable by anyone — the UI was never the lock.

The fast way: let something break it for you

Running all eight by hand every deploy doesn't survive a busy week. Blinkof.ai does it for you: it replays your Server Actions and route handlers without a session, probes for cross-tenant access, checks your env exposure, tries hostile input, and walks your flows — then returns a report where every fix prompt is written for Next.js specifically (middleware, Server Actions, route handlers), not generic advice that doesn't match your stack.

It's this checklist, run in under a minute, by something that knows a Server Action is a public endpoint.