// Security by tool
Security for apps built with Bolt.new
Quick answer
Bolt.new is frontend-first, and that is what creates the most common hole: API keys and paid-provider credentials end up written into the client code. Anyone who opens DevTools reads that key, and automated scrapers find exposed keys on a fresh deploy within hours. Add the Supabase service_role (which ignores RLS) landing in the bundle and you have full database access leaking on screen.
The four holes in almost every Bolt app: exposed service_role, missing RLS, XSS from unescaped input, and auth that exists on the screen but does not verify on the server. If you shipped on Bolt and call a paid API or have login, review it before sending it to a customer.
What Bolt tends to generate wrong
Bolt output pulls a lot of logic into the browser: direct browser-to-provider calls, unprotected functions, no rate limiting, weak CORS. Each one becomes an open door when the app leaves prototype and gets real users.
| Hole | Why it happens | Impact |
|---|---|---|
| service_role in the bundle | Key that bypasses RLS written into the client | Full read/write database access |
| API key in the client | browser→provider call with embedded credential | Key stolen by scrapers in hours |
| XSS from unescaped input | User content rendered without sanitization | Session hijack / script injection |
| No rate limit on form handler | Open endpoint with no request cap | Abuse, spam and provider cost |
How RET reviews a Bolt app
RET starts with what the browser loads: opens the bundle and hunts for keys, service_role and endpoints talking straight to a provider. Then it tests what auth actually blocks on the server (not just the screen) and where user input arrives unescaped. Every finding ships with reproduction and priority.
For the first pass on your own, the Promptbook has specific prompts to sweep the client for keys, check RLS and test the handler. Serious signals go to Risk Review.
- Client bundle sweep for keys and service_role.
- Auth test on the server, not just the component.
- Input escaping, rate limiting and CORS check.
You may already be exposed if
Signals that call for an immediate review in a Bolt app:
- Your app calls a paid API (OpenAI, Stripe, etc.) straight from the browser.
- You use Supabase and do not know if the service_role leaked to the frontend.
- You render user text without sanitizing it.
- Your form/endpoint has no request limit.
Frequently asked questions
Why is a key in the client so serious in Bolt?
Because Bolt is frontend-first and tends to put the call in the browser. Anything in the bundle is public: automated scrapers sweep fresh deploys and find exposed keys in hours, and then the cost (and access) is yours. The fix is moving the key to an environment variable and a server-side function.
What is the difference between anon_key and service_role?
The anon_key is public and respects RLS. The service_role bypasses RLS entirely, it is an admin key. If the service_role lands in the Bolt bundle, anyone reads and writes the whole database. It must never be in the client.
Does Bolt not protect this on its own?
Not by default. It optimizes for prototype speed, not production posture. The server layer, input escaping and rate limiting are steps you (or a review) need to add before real users arrive.
Who runs the review at RET?
Gabriel Lima Ferreira, founder and lead pentester, with authorization and a tight scope, delivering reproducible evidence.