Bolt app security: what to check
Bolt builds full-stack JavaScript apps in the browser and publishes them in a few clicks, often to Netlify. Many Bolt apps use Vite for the front end and Supabase for data and sign-in.
Because the app is generated quickly, settings from the preview environment and keys added for a quick test can end up in the published version. A survey looks for exactly those leftovers.
What to check on Bolt
-
Are secret API keys exposed in your front end?
Variables starting with VITE_ are built into the public bundle, so a secret key given that prefix is readable by everyone.
-
Can anyone read your Supabase tables?
If your Bolt app uses Supabase, row level security is what keeps each user's data private.
-
Are your security headers set?
On Netlify, response headers are set in a _headers file, which generated apps often do not include.
-
Did development leftovers ship to production?
Checks for development builds and localhost addresses that slipped into the published app.
-
Is your site publishing its source maps?
Build tools can publish source maps alongside your JavaScript unless they are switched off for production.
Where settings go on Bolt
- Security headers
- If your Bolt app is deployed to Netlify, add it to a public/_headers file under the path "/*". On other hosts, use the host's custom headers setting.
- Secret keys
- Variables starting with VITE_ are built into the public bundle. Keep the key in a server-side function (for example a Supabase Edge Function or a Netlify or Vercel function) and read it from an environment variable without the VITE_ prefix.
Common questions
Where should secret keys go in a Bolt app?
In a server-side function, such as a Supabase Edge Function or a Netlify or Vercel function, read from an environment variable without the VITE_ prefix.
My Bolt app is on Netlify. Can I add security headers?
Yes. Netlify reads a _headers file from your publish folder, so a public/_headers file in a Vite app is enough.