Bolt.new is safe as a platform, but the apps it generates are not secure by default. In our scan of real Bolt apps, 19.8% had a high-severity flaw. Because Bolt writes the frontend, backend, and database glue, the whole attack surface is generated at once, and the same predictable issues, hardcoded secrets and missing database rules, ship into the export.
From our scan data
19.8% of Bolt apps had a high-severity flaw in our scan, driven mostly by hardcoded credentials.
The risks that actually matter
Hardcoded secrets in generated code
The most frequent high-severity issue. Keys placed inline to make an integration run get exported and, if pushed to a public repo, scraped within hours.
Missing Row Level Security on Supabase
Bolt apps rarely set up RLS, so a public anon key gives anyone full access to the database.
Missing security headers
Generated apps often ship without Content-Security-Policy, HSTS, or X-Frame-Options, leaving room for cross-site scripting and clickjacking.
How to secure a Bolt (bolt.new) app
- Move every hardcoded key into an environment variable before you push.
- Enable Row Level Security on all Supabase tables.
- Add security headers (CSP, HSTS, X-Frame-Options).
- Scan the exported app for inline secrets and missing auth.