bolt + supabase

Bolt + Supabase pre-launch security checklist

Bolt’s speed comes from generating an entire stack in seconds, but the generated defaults are not production defaults. The two recurring problems we see: env values written to deployed files instead of host env vars, and CORS set to wildcard. Walk this list before you ship.

Paste this into Bolt

One prompt that runs the entire checklist as a code review pass.

Audit my Bolt + Supabase app: enable RLS on every public table with ownership policies, ensure the service_role key is NOT in any deployed file or bundle, verify .env is not accessible at /.env, replace CORS wildcard with specific origins, remove any hardcoded API keys from client code, configure CSP/HSTS/X-Content-Type-Options at the host (Netlify or Vercel), set Secure+HttpOnly on session cookies, ensure TLS is valid, publish SPF and DMARC if you send email, and add rate limiting on auth and write endpoints.

FAQ

Frequently asked questions

Why does Bolt expose .env so often?
Bolt sometimes writes config values to project files that get bundled and deployed to /public/ or the root. Search the codebase for any reference to .env content being read at build time vs runtime, and move build-time secrets to host env vars.
Should I leave the Bolt-generated CORS as-is?
No — wildcard CORS plus credentials is the worst combination. Even without credentials, wildcard means any site can call your API. Set an allowlist of your production frontend origins.

Run the scan to confirm each check

60 seconds. Free. No account required.