Is your Bolt app secure?

Bolt.new, from StackBlitz, builds and runs your app in the browser and can deploy it for you, with Netlify as a long-standing option. Apps are often a Vite and React front end with Supabase for the database and login.

Bolt gets the code running and online. It does not decide your database access rules or which variables are safe to expose, and it cannot tell a paid API key from a public one when both are named VITE_. Those parts are yours.

• Supabase tables created by a migration without row level security, so anyone with the public anon key can read them.
• A secret key in .env with a VITE_ prefix, such as VITE_OPENAI_API_KEY. Vite puts every VITE_ value into the JavaScript bundle.
• The Supabase service_role key used in front end code to get past a permissions error.
• No _headers file on the Netlify deploy, so no CSP and no clickjacking protection.
• An AI feature that calls OpenAI or Anthropic directly from the browser instead of through a Supabase Edge Function or Netlify Function.

The .env in a Bolt project holding VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY is normal. Those two are meant to be public. The problem is any other VITE_ value that is a secret.

• Row level security: in Supabase, as a migration Bolt writes or in the SQL editor. Confirm in the Supabase dashboard.
• Secret API keys: in Supabase Edge Function secrets or Netlify environment variables without a VITE_ prefix, used only in the function.
• Security headers on Netlify: a _headers file in public/, which Vite copies into dist on build.

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  Content-Security-Policy: default-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'; upgrade-insecure-requests
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Check this project for security. Enable row level security on every Supabase table and add policies so users only access rows where user_id = auth.uid(). Find any VITE_ variable that holds a secret, move the call that uses it into a Supabase Edge Function, and read the key there from the function's secrets. Add a public/_headers file with security headers. Show me the SQL and file changes first.

1. Open .env and read every VITE_ variable. Only the Supabase URL, the anon or publishable key and other public config belong there.
2. Rotate any secret that had a VITE_ prefix and was deployed.
3. In Supabase, run the Security Advisor and fix every RLS error.
4. Read the policies on tables with personal or paid data.
5. Add public/_headers and redeploy.
6. Scan the live URL.

Test RLS the way a stranger would, with the anon key from your own site and no login:

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5' \
  -H 'apikey: YOUR_ANON_KEY'

Rows back means the table is public. An empty list or a permission error means it is protected.

An outside scan checks what your deployed site hands to every browser: secret keys in the HTML and JavaScript bundles (including a Supabase service_role JWT, while the anon key is correctly treated as public), public .env and .git files, security headers, the https redirect, cookie flags and CORS. It cannot read your database, so the curl test and the Security Advisor are how you check RLS.