The v0 docs do not describe default auth or RLS setup for database integrations; the user chooses and configures the provider.
v0 generates Next.js code with Tailwind and shadcn/ui and deploys it to Vercel. Databases come from integrations such as Supabase or Neon; auth is whatever you connect. Environment variables live on Vercel and only those prefixed NEXT_PUBLIC_ reach the browser.
Because v0 leaves the database and auth choices to you, a v0 app's risk sits in three places. Server actions and route handlers that trust the caller. Environment variables that were prefixed for the browser by habit. The database provider's own rules. The checks below start there.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| Frontend | v0 defaults to Next.js for full-stack apps, with server actions and App Router route handlers for backend code; styling uses Tailwind CSS and shadcn/ui. | docs · verified 2026-09-21 |
| Backend / database | Database integrations (Supabase, Neon, Upstash) are added from project settings or chat; the integration provisions an account on the service and adds the needed environment variables. v0 can generate and run SQL. | docs · verified 2026-09-21 |
| Hosting | v0 deploys projects to Vercel. Every project has a stable production URL on vercel.app; preview deployments come from working branches with unique URLs. Who can access the app depends on the team's plan and deployment protection settings. | docs · verified 2026-09-21 |
| Secrets / env vars | Environment variables are added in Project Settings, encrypted and stored on Vercel, scoped to Development, Preview or Production. The v0 preview can read only Development variables. | docs · verified 2026-09-21 |
| Source access | Connecting GitHub creates a private repository and pushes the current code; v0 works on branches and opens pull requests, and repository rules such as required reviews can block the merge. | docs · verified 2026-09-21 |
| Browser exposure of variables | Only variables prefixed NEXT_PUBLIC_ are exposed to the browser; variables without the prefix stay on the server. | docs · verified 2026-09-21 |
Documentation home: v0.app/docs
37 patterns in the catalogue name v0; the most severe are listed here across secrets and keys, data access, login and permissions, payments, ai features. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
The table looks protected in the dashboard, yet any visitor with the public anon key can read, insert, update and delete every row.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.
Whoever can influence the model's input can delete tables, email your whole customer list, or trigger any other action the app has wired up.
Anyone who views the page source can take the key and run up charges, send messages or pull data on your account until the key is revoked.
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
A scan of 1,645 Lovable-built apps found 170 (about 10.3%) with database endpoints readable without login because Supabase row-level security policies were missing or too broad; recorded as CVE-2025-48757, CVSS 9.3.
May 2025 · Matt Palmer (Replit, Inc.) · all sources
Moltbook, a social network for AI agents built with AI-generated code, ran a Supabase database without row-level security policies, leaving 1.5 million API tokens and 35,000 email addresses readable and writable without login.
Feb 2026 · Wiz Research · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Environment variable handling
v0 relies on the Next.js NEXT_PUBLIC_ distinction and the docs describe automatic analysis and refactoring to keep non-public variables server-side.
Where it stops: Any value you prefix with NEXT_PUBLIC_ is shipped to the browser by design.
vendor docs · verified 2026-09-21
Generated code treated as untrusted
The docs state v0 considers all generated code potentially incorrect or adversarial and applies code analysis, sandboxed execution and input validation before running it.
Where it stops: These controls apply to running code inside v0; the deployed app's authorization logic is still the project's own code.
vendor docs · verified 2026-09-21
Git-based publishing
Changes flow through branches and pull requests; repository branch protections apply to v0's merges.
Where it stops: Only applies when the project is connected to GitHub.
vendor docs · verified 2026-09-21
Enterprise controls
SAML SSO, role-based access, audit logging, separate processing infrastructure and an opt-out from model training for Enterprise customers.
Where it stops: Listed for Enterprise customers.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.service_role and then for sb_secret_.supabase.co, and read the apikey header under Request Headers.v0 pre-launch checklist
37 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your app and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
We check the Next.js server actions and route handlers for permission checks, the bundle for NEXT_PUBLIC_ variables that carry secrets, the Vercel deployment protection settings, and the connected database's access rules. Findings include the file and function to change.
v0's docs state that generated code is treated as untrusted and that only NEXT_PUBLIC_ variables are exposed to the browser. The remaining questions are about your app's logic: does each server action verify the user, and does the database enforce row rules. Both are testable from the outside with two accounts.
Run the Next.js and Supabase (or your provider) self-checks on this site. Then read your environment variables page on Vercel: anything starting NEXT_PUBLIC_ is public. If a secret is there, rotate it and move it.