Browse the blog
Sentrint Blog
Lovable A Lovable security checklist you can finish in an evening Is Lovable safe? What it secures, and what it leaves to you
Bolt Is Bolt safe? The platform is certified. Your app is not covered by that A Bolt security checklist for the hour before you share the link
v0 A v0 security checklist for the Next.js app you just exported Is v0 safe? The generated code is the whole question
Cursor Is Cursor safe? The editor and the code it writes are two questions Every MCP server you added is code you never read
Replit Is Replit safe? The agent deleted a production database, and that was the smaller problem
Base44 Is Base44 safe? A single flaw exposed every private app on the platform
AI-built apps Why AI-generated code keeps shipping XSS, and the four places it hides Supabase RLS is not enough on its own. Here is what else you need Six security checks you can run on your own SaaS in 15 minutes Write a security rules file once, and every prompt inherits it Deleting the key from the file does nothing. It is still in your git history Your app calls an LLM. Everything your users type is now instructions Your paywall is a CSS rule. Here is what it costs and how to fix it The package was real, popular and compromised. Your agent installed it anyway Your AI invented a package name. Someone else registered it Can one of your users read another user's data? Here is how to find out Your API key is in your frontend. Here is how to find it and what to do What the research actually says about AI-generated code security
Bolt · Is it safe?

Is Bolt safe? The platform is certified. Your app is not covered by that

Bolt the platform is genuinely well secured: SOC 2 Type 2, an isolated WebContainer sandbox, annual third-party testing. None of that says anything about the app it generated for you. Its security review is opt-in and off until you turn it on, and your authorisation logic was never in scope.

Gourab Dasgupta Founder, Sentrint 4 min read

When somebody asks whether Bolt is safe, they are usually asking two questions at once and getting the answer to the wrong one. The two have different answers, and only one of them is about Bolt.

Bolt the company runs a well-secured platform, and it publishes the receipts. The app Bolt generated for you is a separate object with a separate answer, and no certificate on the first covers the second.

What is actually certified?

From Bolt's own security page, and these are real and worth having:

  • SOC 2 Type 2, plus GDPR and CCPA compliance
  • An isolated WebContainer sandbox. Your project runs client-side, inside your own browser, not on shared infrastructure. That removes a whole category of risk before it exists.
  • AES-256 at rest, TLS 1.2 or higher in transit
  • Independent third-party assessors testing the platform annually, with pentest summaries available on request
  • 24/7 monitoring with automated scanning and intrusion detection

Read that list again and notice what every item has in common. Each one describes Bolt's infrastructure. Not one of them describes your code.

That distinction is not a gotcha. It is how every platform works. AWS is certified to the eyeballs and still lets you leave an S3 bucket public.

Does Bolt secure the code it writes?

Partly, and more than most. This is where Bolt is genuinely ahead of its peers.

Bolt says it bakes security patterns into generation: Row Level Security "as far as the application allows", authentication patterns that hold up, parameterised queries, escaped output, and security constraints carried in the system prompts themselves. Guardrails at generation time are better than a scan afterwards, and that is a real design decision rather than marketing.

It also offers an automatic security review. Their FAQ describes it plainly: "Turn it on once and Bolt reviews every app before it goes live." When it finds something, one button analyses it, applies a fix, and publishes the secured version at no extra cost.

That is a good feature. Two things about it matter for your app right now.

It is opt-in. "Turn it on once" means it is off until you do. If you have never been into that setting, no review has run on anything you shipped.

"As far as the application allows" is doing a lot of work in that RLS sentence. A generator can follow a pattern. It cannot know that in your app a team_id means shared access but a user_id means private, because you never told it, and the difference between those two is the entire security model of your app.

So what is left for you?

The same list that is left on every platform of this shape. The difference is that on Bolt you may have assumed the review covered it.

Who can see whose data. Change an id in a URL while logged in as a second account. If you can see the first account's records, that is the most common serious flaw in generated apps, and no platform certificate touches it.

API keys in the bundle. Bolt runs your project client-side. That is excellent for build-time isolation and completely unrelated to whether a key ended up in your shipped JavaScript. View source on your deployed app and search for sk-, key, secret and token.

Database grants. Bolt follows RLS best practice, but on Supabase, enabling RLS does not revoke the privileges granted when the table was created. That is Supabase's own documented behaviour and it is a separate step nobody runs. We wrote up the four steps that actually close it.

Your paywall. If a premium feature is hidden with CSS rather than checked on the server, it is free to anyone who opens developer tools.

Business logic. Whether a discount code can be applied twice, whether a form can be replayed, whether an order total is calculated client-side. No generator and no scanner-of-configuration reaches these. They are specific to what you built.

Is Bolt safer than the alternatives?

On the platform, yes, measurably. SOC 2 Type 2 and annual third-party testing put it ahead of most tools in this category, several of which disclose almost nothing about their security practices at all.

On generated code it is ahead of most competitors, because guardrails at generation time and an optional pre-publish review are more than the others offer. On the thing that actually breaks, your application's own logic, it is level with everyone else.

The honest summary is that choosing Bolt was a good decision and it did not finish the job. It could not have.

What should I do this week?

Two things, and the order matters more than it looks. The first takes a minute and the second takes an evening.

Turn on the automatic security review if you have not. It is free, it runs before publish, and there is no argument against it.

Then check the four things it does not cover. Make a second account and try to read the first one's data. View source and search for keys. Look at your Supabase grants, not just the RLS toggle. Call a premium endpoint as a free user.

If you would rather have something read the whole repository than work through that by hand, that is what Sentrint is for. It reads your code and tells you what an attacker would find first, in plain English, with a fix you can paste back into Bolt. A code scan, not a pentest, and the first one is free with no card.

Either way, do the four checks. They take an evening and they cover the flaws that get people.

More on Bolt
A Bolt security checklist for the hour before you share the link Checklist · 5 min read
Enough reading. See your own findings.
A free scan turns this into a list of what to fix, in order.
Run your free scan