Bolt app security: what to check before you launch

Updated Oct 22, 20265 min read

Bolt app security comes down to two places: the keys in your frontend and the Supabase migrations Bolt writes for your database. Bolt has a database audit on all plans and a project audit on paid plans that also reviews code. It can't know which data in your app is meant to be private, so check these yourself before strangers use your app.

What Bolt checks for you

Bolt Cloud projects that need a backend run on Supabase: Postgres, auth, storage and edge functions. Bolt has two checks:

• Database Security Audit (all plans). Bolt's docs say it uses the same checks as the Supabase Security Advisor and checks only your database, not your whole project.
• Project security audit (paid plans). Run from Publish > Run security audit, it reviews code and database, and Bolt's docs say it fixes most problems on its own.

Both are worth running. A database check sees the live policies, which is more than a repo scan can (repo scan vs URL scan has the full split). What it can't tell is whether a policy that lets every account edit a table is a bug or a choice, and the code review can miss things, like any automated check.

Pattern 1: secret keys in VITE_ variables

Most Bolt apps start from a Vite template. Vite's docs say only variables prefixed with VITE_ are exposed to your client code, and that's the point: everything with that prefix ends up in the bundle. A VITE_OPENAI_API_KEY or VITE_SUPABASE_SERVICE_ROLE_KEY is public the moment you publish. Move the call into a Supabase Edge Function and keep the key in its secrets. More on this in VITE_ and NEXT_PUBLIC_ variables are public.

Pattern 2: policies that open whole tables

Bolt writes your schema as SQL files in supabase/migrations. Watch for these in them:

• for all using (true), often named "System can manage ..." or "Public access". Without a to role it applies to everyone, including visitors who never signed in.
• to authenticated using (true) on update and delete. That's every account, and signup is usually open. See why 'authenticated' isn't enough.
• Tables created in SQL without enable row level security (RLS mistakes).

Pattern 3: database functions anyone can call

Bolt often adds security definer functions for things the client can't do under RLS. Functions in the public schema are callable through the API with your anon key. One app in our sample had make_user_admin(user_email) with no check on who is calling, so any visitor could make their own account admin. See security definer views and functions for the fix.

What we found in public Bolt repos

We searched public GitHub code for Bolt's project config (the bolt-vite-react-ts template in .bolt/config.json) and ran our checks on the first 99 repos. 21 of them had Supabase migrations, and 18 of those 21 had at least one high or critical finding.

• 14 of the 21 had a write policy with (true). We read them all: in 10, anyone or any account could change data that isn't theirs, such as pricing settings, the users table or quiz content. The other 4 were mostly public forms like orders and contact messages.
• 12 of the 99 repos read a secret through a VITE_ variable (3 of them copies of one project): OpenAI, Gemini and Groq keys, a Spotify client secret, a GitHub token, an admin password and a Supabase service role key.
• 6 had views or security definer functions that skip RLS.

Shippable published a larger static scan of 4,994 public Bolt repos in October 2026 and reports at least one issue in 51% of them, with open tables the most common. Our sample is small and picked by a search, so it's not a rate across all Bolt apps. We didn't test anything live or contact the owners.

How to check Bolt app security

1. Search for VITE_ secrets

   Search your project for VITE_ and look at every name with KEY, SECRET, TOKEN or PASSWORD. Publishable keys (Supabase anon, Stripe pk_) are fine.

2. Read the migrations

   Open supabase/migrations and search for (true), for all and security definer. Every write policy on user-owned data should compare auth.uid() with the row's owner, admin-only tables need an admin check, and file buckets need storage policies with a folder or owner check.

3. Run Bolt's Security Audit

   Run the database Security Audit, and the project audit if your plan has it. Read the list before you let Bolt apply fixes, so you know what changed.

4. Test logged out

   Call your Supabase REST API with only the anon key and try to read, insert and delete. The vibe coding security checklist has the full test.

// src/services/openai.ts
const openai = new OpenAI({
  apiKey: import.meta.env.VITE_OPENAI_API_KEY,
  dangerouslyAllowBrowser: true,
})

// browser
const { data } = await supabase.functions
  .invoke('suggest', { body: { text } })

// supabase/functions/suggest/index.ts
const key = Deno.env.get('OPENAI_API_KEY')

Fix prompt you can paste

Review this Bolt project for launch. 1) List every VITE_ variable whose
name contains KEY, SECRET, TOKEN or PASSWORD, move each call that uses one
into a Supabase Edge Function that reads the key from its secrets, and
tell me which keys to rotate. 2) In supabase/migrations, list every policy
with (true), every update/delete policy that only checks for a login and
every table without RLS, and rewrite them with an ownership check on
(select auth.uid()). 3) List every security definer function in public
and add an auth.uid() or admin check, or revoke execute from public,
anon and authenticated. Show me each change.

How Leakcade checks this

We read the repo as text. For Bolt apps that means the frontend code for public env variables with secret names, and the Supabase migrations for open policies, tables without RLS, views and functions that skip RLS, and roles read from user_metadata. A Leakcade report lists each finding with the file and line and a fix prompt you can paste back into Bolt. Your live database can differ from the migrations, so compare with Bolt's Security Audit.

Further reading

1. Bolt docs: Check your project's security
2. Bolt docs: Database security settings
3. Vite docs: Env variables and modes
4. Supabase blog: Bolt Cloud launch
5. Shippable: The state of Bolt security

FAQ