Skip to content
ShipSecurelySecurity reference
Menu

23 tools · 100 fixes · 27 incidents tracked · Updated Oct 14, 2026 · Sources: GitHub, Supabase, OWASP, Stripe + 24

Issues

Bolt apps, secrets, and Supabase access

Vite documents that VITE_ values are bundled into the client, and Vercel's Bolt export guide says the Secrets panel values are not in the zip you deploy.

Share link · Share on X

Last updated

criticalSecrets

Shows up in: Supabase, Vercel

Markdown version

What it is

Bolt's own product docs were not the source for this page. Two vendor pages describe the stack a Bolt app often ships with. Vite's env guide says variables prefixed with VITE_ are exposed in client source after bundling, and that those variables should not contain API keys. Vercel's guide to deploying a Bolt project says Bolt does not include Secrets panel values in the exported zip, so API keys are missing until you recreate them as Vercel environment variables.

If the app talks to Supabase, Supabase's securing-data guide still applies: the publishable key may be in the client only with row level security and grants, and a secret key bypasses RLS. This page does not claim a count of Bolt apps that ship with RLS off. That number was not on the pages above.

How to check in 5 minutes

  1. Search the Bolt project for VITE_ and open the built JavaScript if you have a production build. Vite's guide says a VITE_ value is in the client bundle and a variable without that prefix is not.

  2. If you exported a zip for Vercel, open the Vercel project's environment variables. Vercel's Bolt guide says Secrets panel values are not in the export. A missing key fails closed. A key you pasted into a VITE_ name fails open.

  3. If the app uses Supabase, open the table's RLS flag in the Supabase dashboard. Confirm a signed-out request with the publishable key does not return another user's row.

How to fix

Bolt

Remove the VITE_ prefix from any value that is a secret, and stop reading it from import.meta.env in client code. Call the third party from a server or edge function. Keep the Supabase publishable key as the client key only after RLS is on.

Vercel

Recreate Bolt secrets as Vercel environment variables, using the Secret type for credentials. Vercel's env docs say Secret values are write-only after saving, and Config values stay readable. Redeploy. An old deployment keeps the previous values.

Supabase

Enable RLS and policies for the roles the client uses. Do not put the secret key in a VITE_ variable. Supabase says that key bypasses RLS.

Copy-paste prompt

Paste this into Cursor, Claude Code, or whichever agent is editing the repo. Read the diff before you merge it.

You are fixing secret exposure in a Bolt project that uses Vite. Do not add features.

1. List every VITE_ variable. Any secret in that list moves to a server-side env var and out of client code.
2. If the app uses Supabase, enable RLS and show the policy. Do not put the secret key in the client.
3. Do not invent a statistic about Bolt apps. Show the files you changed.

Questions

Does the Vercel export include Bolt secrets?

No. Vercel's Bolt deployment guide says the Secrets panel values are not in the zip, and that you recreate them as Vercel environment variables before features that call external services will work.

Does Vite hide a VITE_ key?

No. Vite's env guide says the prefix exists to expose values to client code, and that API keys should not use it.

Sources

Related