How to secure your Bolt app before you share the link

Bolt is great for getting an idea running fast. The risk is that the generated app often puts everything in the frontend, including things that should stay secret.

1. Find keys in the frontend

Open your project and search for apiKey, sk-, secret and token. Any key for a paid service (OpenAI, Stripe, Resend, Twilio) must not be in the frontend, because the published site sends it to every visitor.

Find every place a secret API key is used in the frontend code. Create a server-side function (a Netlify function, Supabase Edge Function or similar) that makes the call, move the key into that function’s environment variables, and change the frontend to call the function. Remove the key from the source.

Rotate any key that was ever published.

2. Check your environment variables

In Vite projects, variables starting with VITE_ are bundled into the site. Use that prefix only for values that are meant to be public, such as the Supabase URL and anon key.

3. Lock the database

If you connected Supabase, turn on Row Level Security for every table and add policies.

Enable Row Level Security on all public tables and add policies so each signed-in user can only read and change their own rows. Never use the service_role key in the frontend.

4. Do not publish extra files

Make sure your published site does not contain .env, .git or backup files. Open your-site/.env in a browser: it should show “not found”.

5. Add security headers

Your host (Netlify, Vercel or similar) lets you set headers. At least add Strict-Transport-Security, X-Frame-Options and a Content-Security-Policy.

Check it

Paste your published address into Greenlight Scan. The free preview counts the problems; the full scan gives a Bolt-ready prompt for each fix and lets you re-scan for 30 days.