Originally published on the Axieo blog.

Bolt.new can turn a prompt into a working app with a database, logins and hosting in an afternoon. That speed is the point. But an app that works in the demo isn't automatically safe with real users, and the gaps are usually in the parts you never asked for.

This checklist is written for founders, not security experts. It covers what Bolt checks for you, what it doesn't, and what to test yourself before you share the link.

1. How a Bolt app is put together

Most Bolt apps have a front end that runs in your visitors' browsers and a database behind it. Bolt's docs say "every Bolt project can have a built-in database", and on Pro or Teams plans you can choose Supabase instead when you create the project.

Either way, the database is protected by Row Level Security (RLS): rules that decide who can read and change each row. Bolt's database security page puts it plainly: "A table without RLS can be read and changed by anyone."

2. Database rules (the most important part)

Bolt "turns on RLS for the tables it creates". That's a good start, but turned on isn't the same as correct. Bolt's docs also say that for apps without sign-in, it "might write policies that allow any visitor to view, add, change, and delete the data in your database."

  • Open the Security tab and look for the RLS Policy Always True warning. Bolt says this tab "uses the same database checks as the Security Advisor in Supabase". An always-true rule on user data means anyone can read or change it.
  • Check tables you or your team added later, outside Bolt. Every table needs RLS.
  • Do the two-account test. Sign up as user A and create something. Log in as user B in another browser and try to see or change A's data. If you can, the rules need to compare the logged-in user with the row's owner.
  • Keep private files in private storage. ID scans, invoices and contracts shouldn't be in a public bucket.

3. Secret keys

Bolt apps are usually built with Vite, and Vite's docs are clear: "VITE_* variables should not contain sensitive information such as API keys." Every VITE_ value ends up in the browser, where anyone can read it.

  • Only public values in VITE_ variables: your database URL and the publishable (anon) key. Never a Stripe secret key, an AI provider key or a database admin key.
  • Keep real secrets in Bolt's Secrets settings and use them only in server-side code.
  • If your project syncs to GitHub, check that no .env file or key was ever committed. Deleting it later doesn't remove it from git history. If a secret was ever exposed, rotate it.

4. Logins and admin pages

  • Admin pages must be protected by the database and the server, not just hidden in the menu. Anyone can open the browser's developer tools.
  • Roles such as "admin" must not live in a field users can edit on their own profile.
  • Email confirmation on, sensible password rules, and redirect URLs limited to your own domains.

5. Payments

  • Stripe webhooks must verify the signature, or anyone can send a fake "payment succeeded". See Stripe's webhook docs.
  • Prices and paid features are checked on the server. If the browser decides what's unlocked, people can unlock it themselves.

6. Hosting

Bolt can publish your app to an address ending in bolt.host, or you can deploy elsewhere. If you use Netlify, note that Bolt's Netlify page says it "can't host a database or a traditional backend", so make sure every server-side check still runs somewhere secure.

  • HTTPS only, plus basic security headers (a Content-Security-Policy and clickjacking protection).
  • Run npm audit for known-vulnerable packages.
  • Separate test data from real users' data, and know how you'd restore a backup.

7. Use Bolt's own security tools first

Bolt has a database check on all plans and a fuller project security audit on paid plans. Bolt's security docs suggest running the audit "at least once before you publish". It checks, among other things, that "private keys and passwords aren't stored in your project's code or sent to visitors' browsers."

Run it, and review every change it proposes before you accept it. A tool can only check what it was designed to check. It can't know that a table was meant to be private, or that a manager shouldn't see another team's data. That's what the two-account test and a human review are for.

8. Where to start

If you only have an hour: run Bolt's database check and fix every RLS Policy Always True warning on user data, search your code for secret keys, and do the two-account test. Our free 10-point security self-check walks through these for Supabase-style databases, with where to click.

Want a second pair of eyes?

Axieo Guard is our security audit for AI-built apps, including apps built with Bolt.new. A free mini scan checks five high-impact items, including exposed keys and open database tables. A full audit covers 25 checks, with a plain-English report and a recommended fix for every finding. We're a Canadian company, and we only test with your written permission, read-only. Get a free mini scan.