Bolt.new security: check before you publish

01What Bolt.new checks for you

According to Bolt.new’s documentation, you get two kinds of checks:

Run both and fix what they find. They are the cheapest wins you’ll get. Note that leaked-password protection needs a paid Supabase plan, so on a free plan that finding stays open.

02What project checks can’t see

A review of your project answers “does this code look right?”. Some problems only exist in the running app:

• What actually shipped. Env values are inlined at build time. The source says import.meta.env.VITE_OPENAI_KEY; the bundle contains the key itself.
• Policies under real conditions. A policy can look reasonable and still let user A read user B’s rows, because of a missing owner check, a view that skips RLS or a function that runs as its owner.
• Who can become “authenticated”. If email confirmation is off, anyone can create accounts, and every “signed-in users only” rule becomes nearly public.
• Hosting and headers. Exposed .env or source map files, missing security headers, CORS that allows any site.

None of this is a criticism of the built-in checks. It is the difference between reading the plans and walking through the building.

03The VITE_ trap: keys in your bundle

Bolt.new projects are usually built with Vite. Vite exposes every variable starting with VITE_ to the browser code, by copying its value into the bundle (Vite docs). That is right for your Supabase URL and publishable key, and wrong for everything else.

# fine in the browser
VITE_SUPABASE_URL=https://abcd.supabase.co
VITE_SUPABASE_ANON_KEY=sb_publishable_...

# never with a VITE_ prefix: these end up in public JavaScript
VITE_SUPABASE_SERVICE_ROLE_KEY=...
VITE_OPENAI_API_KEY=...
VITE_STRIPE_SECRET_KEY=...

Move anything secret into a Supabase Edge Function or another server route, store it as a function secret, and call the function from the browser. If a secret already shipped, rotate it; removing it from the next build does not un-leak it. For Supabase keys, see the service_role guide.

04How to test your published Bolt.new app

1. Search the bundle. Open the published site, DevTools → Sources, and search for sk-, sk_live_, sb_secret_, re_ and eyJ. Decode any JWT and check its role.

2. Count what a stranger can read. Take the Supabase URL and public key from the bundle and ask for a row count, signed out:

curl -I "https://YOUR_REF.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_PUBLIC_KEY" -H "Prefer: count=exact"
# content-range: */0 → nothing public.  0-24/812 → 812 rows readable by anyone

3. Check sign-up. curl "https://YOUR_REF.supabase.co/auth/v1/settings" -H "apikey: YOUR_PUBLIC_KEY" shows whether sign-up is open and whether emails must be confirmed.

4. Test as two users. Create two accounts. As user A, request user B’s rows by id, try to insert a row with B’s user_id, and try to set your own role or credits. The RLS checker guide has the exact requests.

5. Check the hosting. Try /.env, /.git/config and .map files on your domain. Each should be a 404.

05A prompt to fix what you find

Paste this into Bolt.new after a finding, and review the diff before accepting it:

Fix this without weakening security elsewhere:
- Every table in public has RLS on, with policies that compare user_id to (select auth.uid()).
- Separate policies for select, insert (with check), update (using + with check) and delete.
- Users cannot change role, plan, credits or is_admin on their own rows.
- No secret key uses a VITE_ prefix. Move secret calls into a Supabase Edge Function.
- Don't use the service_role key in browser code, and don't make any table or bucket public to fix an error.
Show me the SQL you ran.

06What Preflight checks on a Bolt.new app

Preflight looks at the published app from outside, which is the part Bolt.new’s checks don’t cover. The free scan searches your live JavaScript for more than 15 kinds of secret keys, tries .env, .git and source maps, checks headers, cookies, CORS, TLS and known-vulnerable libraries, and, if your app uses Supabase, counts what the public key can read on up to 35 tables and reads your sign-up settings. The $29 Proof Report runs the two-user test from step 4 with test accounts you create. Preflight doesn’t run your webhooks or Edge Functions. If your app doesn’t use Supabase, the Supabase checks are skipped and the Proof Report isn’t offered.

?Questions people ask

• Is Bolt.new safe to build production apps with?

  Bolt.new gives you the same building blocks as any Vite and Supabase app, plus built-in security checks. Whether the app is safe depends on its policies and where its keys live, so check the published app before real users arrive.

• Does Bolt.new hide my API keys?

  Only keys kept in server code or Edge Function secrets. Anything with a VITE_ prefix is copied into the browser bundle, where anyone can read it.

• Is Bolt.new’s security check free?

  The database security checks are available on all plans. The whole-project review in the Publish menu is on paid plans, according to Bolt.new’s docs.

• Is my Supabase anon key exposed in Bolt.new?

  Yes, and that is expected. It is public by design. What matters is what your RLS policies let it read. See the anon key guide.

• How do I test my Bolt.new app for data leaks?

  Count rows readable with the public key, signed out, then test as two signed-in users. Preflight’s free scan does the first part automatically.

→Related guides

• Supabase RLS checkerTest row level security as no one, then as two users. SQL and curl included.
• Lovable security scanWhat Lovable’s Quick and Deep scans cover, and how to test the live app yourself.
• Supabase anon key exposed?Why the anon or publishable key is meant to be public, and what actually leaks.
• Supabase security checklist24 checks with SQL, grouped, each marked with whether Preflight tests it.
• Supabase service_role key leakedConfirm the leak, rotate without downtime, and check what was touched.
• Supabase storage: public vs private bucketsPublic vs private buckets, owner-folder policies, signed URLs and how to test them.
• Vibe coding security checklist20 checks for apps built with AI tools, from data leaks to headers and email.