Home / Guides / Bolt.new security checklist

Bolt.new security checklist: database, keys and Netlify settings

Bolt projects are usually Vite-based web apps. By default they use Bolt Database; on Pro and Teams plans you can use Supabase instead. You can publish to Bolt hosting or to Netlify. Whatever you pick, the same rule applies: anything the browser downloads is public.

Scan your live app free Passive, no signup, never touches your database.

1. Know which database you're on

Per Bolt's docs, new projects use Bolt Database by default, and Supabase is available on Pro and Teams plans. If you're on Supabase, everything in our Supabase RLS checklist applies: enable RLS on every table and scope policies to auth.uid().

2. Treat every VITE_ variable as public

Vite exposes only VITE_-prefixed variables to client code, and those values end up in your JavaScript bundle. A Supabase URL and anon key are fine there. A service role key, Stripe secret key or OpenAI key is not.

3. Use edge functions for payments and AI calls

Bolt's Supabase docs note that edge functions are used when the app needs an API, for example for Stripe payment handling. Keep secret keys in the function's secrets and verify the caller.

4. On Netlify, mark secrets as secrets

Netlify's Secrets Controller lets you flag environment variables as secret; Netlify then applies a stricter policy and scans builds for embedded secret values. Don't put secret values into variables that get bundled into the front end.

5. Add security headers

On Netlify, add a public/_headers file (snippet in our HSTS and CSP guides) so it ships with every deploy.

6. Don't ship source maps

Set build.sourcemap to false in vite.config so production .map files aren't published.

7. Check what got deployed

Run Unspill on your live URL. It checks your bundle for secret keys, public source maps, an exposed .env and missing headers.

Fix guides for these issues

Verify Supabase Row Level Security: Your Supabase anon key is public by design, so Row Level Security is the only thing protecting your tables. Run these SQL checks to find tables with RLS off or policies that let anyone read everything.
Stripe secret key exposed: A Stripe sk_live_ or sk_test_ key in your JavaScript lets anyone create charges, issue refunds and read your customers. Roll the key in the Stripe Dashboard and move payments server-side.
AI API key exposed: An OpenAI, Anthropic, Groq, OpenRouter or xAI key in your front-end bundle lets anyone run up your bill. Revoke it and proxy AI calls through a server function with rate limits.
Public source maps: Production .map files let anyone rebuild your original front-end code, comments and internal routes. Disable them in Vite or Next.js, or upload them privately to your error tracker.
HSTS: HSTS tells browsers to always use HTTPS for your domain, preventing downgrade attacks on public Wi-Fi. Add one header in vercel.json, _headers or next.config.js.
Content-Security-Policy: A Content-Security-Policy limits which scripts can run on your site, reducing the damage of XSS. Copy-paste CSP examples for Vercel, Netlify and Next.js apps using Supabase.
Exposed .env file: If https://yourapp.com/.env downloads your environment file, every secret in it is public. Remove it from the deployed output, block dotfiles, and rotate every key.

FAQ

Are VITE_ environment variables secret?

No. Vite inlines VITE_-prefixed variables into the client bundle, so anyone can read them. Use them only for values meant to be public.

Do I need Supabase to build a secure Bolt app?

No. Bolt Database is the default. If you use Supabase, Row Level Security policies are what protect your data from direct API access.

Sources

Last checked against these sources on 2026-10-19. Platforms change; when in doubt, the official docs win.