v0 app security check

v0’s Vercel integration docs say the first time you publish, a Vercel project is created, and environment variables are inherited from that project. The same page says the v0 preview can only access Development environment variables, and that sensitive environment variables are inaccessible to the preview. That limit is about the preview inside v0. It is not a description of the JavaScript that gets deployed. Source: v0 Vercel integration.

When the generated app is Next.js, Next.js inlines any NEXT_PUBLIC_ value into the browser bundle at next build. A Stripe secret, a service role key, or another server credential does not belong in that prefix, and it does not belong as a string in a client component. If the generated app is Vite, the equivalent prefix is VITE_. Sources: Next.js environment variables and Vite env variables.

The published URL can also serve a source map, skip security headers, or include a Supabase client config. Missing row level security on that Supabase project is common and invisible to a fetch of the homepage.

The free Quick Check fetches the public HTML, same-origin JavaScript, security headers, cookie flags, and whether the URL stays on HTTPS. It also requests seven fixed paths: /.env, /.env.local, /.env.production, /.git/config, /.git/HEAD, /.aws/credentials, and /.npmrc. Source maps named by those scripts are included. Matched secrets are masked. The free page writes the fix for the single most serious finding.

It does not query tables. It does not test row level security. It does not log in, brute force, fuzz, or enumerate paths beyond that list. An anon Supabase key in the bundle is client configuration. A service_role key in the bundle is a finding. Neither one tells you whether policies exist.

The €19 Launch Report opens the rest of that same pass. It does not scan anything new. Monitor, €9 per month, repeats the same passive check each week and when a deploy hook fires. It will not notice a table with row level security off.

Publish, then run the free check on that URL. The v0 preview is not the check.

Rotate any secret the report shows in the HTML or a script. Remove it from client components and from NEXT_PUBLIC_ or VITE_ names. Keep server values in the Vercel project’s environment without a public prefix, and read them from server code.

Then fix headers and source maps on the deployment, and confirm Supabase grants and row level security yourself.

If a .js.map file is public, turn off maps that ship to browsers, or keep stack traces without serving the files. In Vite set build.sourcemap to 'hidden' (or false to omit maps). In webpack set devtool to 'hidden-source-map'. In Next.js leave productionBrowserSourceMaps off, which is the default. Upload the maps to your error tracker in CI, then delete the .map files from the deploy output. A hidden map is still public if the file is deployed beside the script. Vite documents 'hidden' as a map file without the sourceMappingURL comment. Webpack documents hidden-source-map the same way. Next.js documents that production browser source maps stay off unless you opt in.

Missing headers are fixed on the host that serves the published URL. The check looks for Content-Security-Policy, Strict-Transport-Security on HTTPS, clickjacking protection (X-Frame-Options or CSP frame-ancestors), X-Content-Type-Options, and Referrer-Policy.

If the app uses Supabase, open the RLS check and the 30 October grant note. Confirm row level security and the GRANT yourself. Disabling RLS is not the fix for a missing grant. This scan does not query tables, so it cannot do that confirmation for you.