Bolt.new turns a prompt into a full-stack app — usually a React/Vite or Next frontend on a generated backend — in minutes. The failure modes cluster around what gets generated fast: secrets, backend rules, and server-side checks. Here’s what to close before real users arrive.
Secrets generated into the client
Fast full-stack generation makes it easy for an API key or backend secret to land in the frontend bundle. Once it ships, it’s public — and rotating the key is the only real fix.
Check: Search the generated client and built bundle for keys or secrets that should be server-side only.
Backend rules in test mode
Generated Supabase or Firebase backends frequently ship with permissive rules — allow read, write: if true, or USING (true) — so the app works immediately. That leaves the data readable, and often writable, by anyone who finds your public config.
Check: Read your database rules/policies. if true / USING (true) means open.
No server-side authorization
Generated endpoints and actions often check nothing on the server — the only “protection” is the UI not showing a button. Anyone hitting the endpoint directly is straight in.
Check: Does each endpoint verify who is calling, and that they’re allowed, before it acts?
Trusted input, leaked errors
Generated handlers tend to trust their input and either crash or leak a raw stack trace on bad data — a reliability problem and an information leak that hands an attacker a map of your internals.
Check: Is user input validated server-side, and are errors handled cleanly — no stack traces shown to the user?
No rate limiting
Open signup, auth, and any paid or third-party endpoint can be hammered or run up cost when nothing throttles them.
Check: Is there a limit on signup, auth, and anything that costs money to call?
Before you go live
- No secret anywhere in the frontend bundle.
- Backend rules scoped to the user — no
if true. - Server-side auth on every endpoint; input validated.
- Rate limits on costly endpoints.