Public env vars, the Supabase anon key, and row level security

Two public prefixes put an environment variable in the browser. This page is that pattern in two cases: a Bolt project that uses Vite, and a v0 project that uses Next.js. It is not a count of Bolt or v0 apps, and it is not a claim about every app.

Vite's env guide says a variable prefixed with VITE_ is exposed in client source after bundling, and that VITE_* variables should not contain sensitive information such as API keys, because those values are bundled into source at build time. A name without that prefix is not exposed that way. The guide's example is VITE_SOME_KEY visible through import.meta.env, and DB_PASSWORD undefined there.

Vercel's v0 docs say v0 works with tools like Next.js. Next.js environment variables say that, by default, a variable without the NEXT_PUBLIC_ prefix is only available in the Node.js environment, and that prefixing a variable with NEXT_PUBLIC_ inlines the value into the JavaScript sent to the browser when you run next build. The env option in next.config is a separate path: a name listed there is included in the JavaScript bundle even without NEXT_PUBLIC_.

Supabase API keys say the publishable key is what you ship in a browser, and that anyone can read it, so it only reaches what row level security allows. With nobody signed in, that key is the anon role. With a signed-in user, it is authenticated. The secret key is service_role. It bypasses row level security, and it must not go in a browser, a shipped app, or source control. The legacy anon key is the older publishable key. The legacy service_role key is the older secret key. Supabase says it is deprecating both legacy keys by the end of 2026.

Postgres checks grants before row level security. The same guide says a missing grant returns a permission error, including for service_role, and a policy that matches no rows returns an empty result. Securing your API says a table or view exposed through the Data API without row level security can be accessed by any role with a matching grant. A missing grant on a new table is the separate failure in New Supabase tables need an explicit grant.

Keep the two rules apart.

Safe to put in VITE_ or NEXT_PUBLIC_: the project URL and the publishable key. Supabase documents that key as safe to expose in a web page, and it only reaches what row level security allows. That holds when row level security is enabled and the policies for anon and authenticated are the ones you mean. Vite's warning about API keys still applies to a secret key, a service_role key, or any other credential. The Vite page and the Supabase page do not collapse into one rule.

Not safe to expose: a secret key or a service_role key in VITE_ or NEXT_PUBLIC_. The API keys guide says that key bypasses row level security. Next.js inlines NEXT_PUBLIC_ into the browser bundle at next build. Vite bundles VITE_ into client source.

What row level security has to enforce: policies for anon and authenticated. The API keys guide says policies never apply to a secret key, because service_role has BYPASSRLS. A publishable key in the client is not a substitute for those policies.

You are checking public environment variables in a Bolt, Vite, v0, or Next.js project that uses Supabase. Do not add features. Do not invent a count of insecure apps.

1. List every VITE_ and NEXT_PUBLIC_ name, and every name under env in next.config. Vite bundles VITE_ into client source. By default Next.js inlines NEXT_PUBLIC_ at next build. A name in next.config env is also in the browser bundle. A Vite name without the VITE_ prefix is not exposed that way.
2. The Supabase project URL and publishable key may use that prefix. The secret key and the legacy service_role key may not. Supabase says the publishable key is public and only reaches what row level security allows. The secret key bypasses row level security.
3. Enable row level security and show the policies for anon and authenticated. Do not turn row level security off. Do not grant every command to anon to hide a permission error.
4. A missing grant is a permission error. A policy that matches no rows returns an empty result. Do not treat that empty result as a missing grant.
5. Do not print secret values. Show the files you changed and the env var names the host needs.