What security each app builder ships by default
By Kike Gandia · Co-Founder & CEO, OSCP
Lovable, Bolt, v0, Replit and Base44 share one product decision: remove friction so you see your application running within minutes. That decision has security consequences which are identical across all five and worth understanding before you publish. This comparison describes what each one ships out of the box across the four layers where problems concentrate, and what is left for you to close. None of the five is insecure: what differs is how much work they do for you and how loudly they warn you.
Comparison: what ships by default and what is left to you
All five delegate access control to the data layer configuration. That is the conclusion that matters.
| Builder | Usual data layer | Authentication | Access control by default | What you have to close |
|---|---|---|---|---|
| Lovable | Supabase, integrated | Included, ready to use | Row Level Security off when tables are created | Enable RLS and write ownership policies |
| Bolt | Supabase or whatever you connect | Depends what you integrate | Depends on the provider you connect | All access control, plus reviewing generated code |
| v0 | Whatever you connect | Not included out of the box | None: it starts from the interface, not the backend | Backend, authentication and authorisation in full |
| Replit | Own database or Supabase | Own auth available | Permissive while you develop | Review secrets and permissions before publishing |
| Base44 | Built into the platform | Included | Its own permission model, to be configured | Define roles and visibility per entity |
The deciding column is the fourth. In all five cases the answer to "who may read this record" does not come solved: it comes ready for you to solve.
Why all five look so similar
It is neither coincidence nor negligence: it is the same architecture. The browser talks to the database directly using a public key, with no intermediate server filtering anything. It is a modern, efficient and perfectly secure pattern when the access rules are written.
The difference from traditional development is where the decision lives. Previously your server decided what to return to each user; now the database decides, row by row, according to the policies you defined. If you define none, there is no decision: everything is returned.
That is why the comparison matters less than it looks. Whichever you pick, the outstanding work is the same, and whoever comes asking for it — a client, an investor, the GDPR — does not ask which tool you built with.
Where the real differences are
How loudly they warn you. Supabase visually flags tables without RLS and documents it prominently. A builder sitting on top may surface that warning or not, and there is genuine variation between products and between versions.
Whether there is code you can read. With v0 and Bolt you end up with code a developer can review. With more closed platforms, the review is of configuration rather than code. It changes how you audit, not the risk.
What happens with secrets. Those offering server-side environment variable management let you get keys out of the browser; front-end-only ones do not. It is the most practical difference in the whole table.
What you take with you if you leave. Being able to export the project determines whether you can hire somebody to review and fix it, or whether you depend on the platform for everything.
How to choose with security in mind
If you are still deciding, three questions order the choice better than any comparison table:
1. Can I keep secrets out of the browser? If the answer is no and your product charges money or sends email, the problem is structural rather than configuration.
2. Can I export the project? It determines whether you will be able to audit and fix it with somebody external.
3. Does the platform warn me about what is left open? A visible warning is the difference between forgetting it and not forgetting it.
And if you have already built, the question is a simpler one: not which you chose, but whether the access rules are written. That is checked in fifteen minutes and does not depend on the product.
FAQ
Which of the five is the most secure?
The question does not quite hold, because none of them sets the security level of the application you build with it: the configuration you leave in place does. What can be said is that those letting you keep secrets server-side and export the project leave you better positioned, because they remove a structural problem and allow somebody external to review the result.
Do the defaults in this table change?
Yes, and frequently: these products iterate fast and several have tightened their defaults in recent months. Use the table as a map of which layers to inspect rather than as a permanent truth, and verify the actual behaviour of your own application, which is the only thing that counts in an audit.
I already built with one of them, should I switch?
It is rarely worth it. Migrating builders is a full project and does not solve the problem, because the outstanding work — writing access rules, getting secrets out of the front end, checking authorisation between users — is the same at the destination. Closing what you have open where you already are is far cheaper.
Related service
Related content
- Supabase without RLS: why data leaks
- Is an app built with AI secure?
- Check in 15 minutes whether your app leaks data
- The 7 most frequent flaws in AI-generated apps