Built with Bolt
Is my Bolt app secure?
Bolt did its job. It built you a real app in minutes. The question is whether the access rules around it hold up. Bolt provisions its own managed database by default, and the thing that decides who can read and change what is the rules around that database, plus whether any secret has ended up in the client. So "is my Bolt app secure?" is really "are my database rules right, and are my secrets out of the browser?" The checks below are the ones to run before real users, payments or investors depend on the app.
What Bolt generates under the hood
Bolt builds full-stack JavaScript web apps across a range of frameworks. When the app needs persistence it provisions its own managed Bolt Database by default, with its own authentication, file storage, server functions, tables and user management. Supabase is an optional alternative, available on the Pro and Teams plans. It publishes to Bolt's own hosting at a free .bolt.host domain by default, with Netlify available as an opt-in, and the app runs on StackBlitz WebContainers. The problems that usually turn up are specific to that stack, not to Bolt itself.
The problems that usually turn up
These are the things that usually turn up in Bolt apps, in plain English. Each one points to where to go deeper, the launch checklist and the guides, rather than restating them.
- Anyone can read every customer's data. If the database rules are off or too broad, any logged-in user, or sometimes anyone, can read or change every row. With Bolt that is the rules on the Bolt Database by default, or the Supabase rules when you have chosen Supabase. (row-level security) The launch checklist, check 02.
- A secret that ships to the browser. An API key or database credential that ended up in a .env file the client can read. Anyone who opens the app can read it and use it against your database. (exposed credentials) The launch checklist, check 01.
- A server function with no auth check. A route that does something on your behalf without checking who is asking. A stranger can trigger it, and it can cost you money or change data. On Bolt that is a function on Bolt Cloud by default, or a Netlify function when you have opted into Netlify. (broken access control) The launch checklist, check 02.
These are a few of the common pitfalls, and there are many more. The full list is on the launch checklist.
The DIY checks
Work through these on your own. They are free, and there is nothing to sign up for.
- The launch checklist. The questions to ask your AI before you launch, each with what a good answer looks like.
- Is my AI-built app safe to launch?. The three things AI-built apps keep shipping with.
- I built it with Lovable, Bolt or Cursor. Does that matter?. Why the tool does not matter, and what does.
- How much does my app cost to run?. The cost drivers and the exploits that ramp the bill.
Which shakedown fits
The Quick Shakedown (from AUD 750) is the right fit for a Bolt app. It covers the exact things Bolt apps get wrong: exposed keys, open data, broken access. If you want the whole app reviewed rather than just the highest-risk parts, the Full Shakedown (from AUD 1,500) goes through everything and hands back the engineer-ready clean-up. If you are prepping for a launch or a raise, Launch-ready (from AUD 2,500) adds the written brief your first hire, or your AI, can work from. Every price is "from", quoted up front for the size of your app and fixed once agreed.
Want it done for you?
I can go through all of it with you
A shakedown is me asking every one of these questions, of your whole app, and handing back a ranked report with a fix your own AI can apply. Quoted up front for the size of your app, fixed once agreed.
Not sure which one? Book the free 30-minute call and I'll help you choose.