Bolt app security checklist: 12 checks before you hand it to customers

Bolt app security comes down to one question: when a real customer signs in, can they only see and change what's theirs? Bolt makes it easy to get a working app in front of people fast, and it now ships its own security tools. But a scan that says "no issues" is not the same as proof that a stranger can't open your customers' orders. This checklist gives you 12 checks you can run yourself in about an hour, in plain English, before you hand a Bolt app to clients or start charging for it.

If you'd rather have a person do this with you, our Bolt app security audit is a human review of the same ground: who can see which records, where your keys live, whether payments can be skipped, and whether your backups actually restore. If you want to try it yourself first, keep reading. You can also start with our free self-check, which takes a few minutes.

What Bolt already checks for you

It helps to know what Bolt does on its own, so you don't repeat work or assume too much. According to Bolt's support docs, there are two built-in checks:

• Project security audit. Run it from the Publish menu with Run security audit. It reviews your code and database, fixes what it can, and lists "needs your action" items in the chat. Bolt says this button doesn't use your tokens, while asking Bolt to audit in the chat does. It's on paid plans.
• Database security check. The Security tab in your database settings flags missing row-level security (RLS) and access rules that are too open. It's on all plans, and Bolt notes it checks only the database, not your whole project.

Bolt's audit covers who can see and change data, what your app makes public, sign-in, misuse (like changing a price or claiming a single-use item twice), visitor input, and keys. That's a solid list. What it can't do is know your business. It doesn't know that a "team" should only see its own projects, or that a coupon should work once per customer, unless that rule is written down somewhere it can read. That's where your own checks come in.

Before you start

Have these ready:

• The live link your customers use, not the preview inside Bolt.
• Two test accounts with different email addresses. Call them Alice and Bob.
• A private browser window so you can be "signed out" without logging out of Bolt.
• Your database open in Bolt (the database icon at the top of the screen), or your Supabase dashboard if you connected your own Supabase project.

Write down what you find as you go. A short list of "pass", "fail" or "not sure" is all you need.

The Bolt app security checklist (12 checks)

Part 1: Who can see what (checks 1 to 4)

1. Run Bolt's own audit first. Click Publish, then Run security audit, and read the "needs your action" items. Do them before anything else. If you're on a free plan, open the database Security tab instead and read every warning.

2. Read every "RLS Policy Always True" warning out loud. Bolt's docs explain that this warning means a rule has no conditions, so any visitor can view, add, change or delete that data. Bolt flags it even when public access is intended, which makes it easy to dismiss. For each table, decide which of three cases it is: anyone can view it (a menu or blog), anyone can add to it but not read it back (a contact form), or it's private (orders, messages, invoices). Private data needs sign-in plus a rule that limits rows to their owner.

3. Run the two-account test. Sign in as Alice and create something private: an order, a note, a project. Copy the link to it. Open a private window, sign in as Bob, and paste the link. If Bob sees Alice's data, you have a real problem, whatever the scan said. We walk through this test in detail in the two-account test.

4. Try it signed out. In a fresh private window with nobody signed in, open the same links and any "dashboard" or "admin" pages. You should get a sign-in screen or an empty page, never data. Then check that signing out really ends the session: sign out, press the browser's back button, and refresh.

Part 2: Keys and secrets (checks 5 to 7)

5. Confirm paid-service keys are in Secrets, not in code. Bolt's docs say API keys and passwords belong in the database Secrets tab, where server functions can read them without sending them to the browser. Open Secrets and check that every outside service you use (OpenAI, Stripe, email) is listed there.

6. Search the live site for keys. Open your live link, right-click, choose View page source, and search for sk_, sk_live, secret, and service_role. Then open developer tools (F12), go to the Sources tab, and search all files for the same words. A Supabase publishable or anon key in the browser is normal. A secret key, a Stripe secret key or an OpenAI key is not. Our post on how keys leak into browser code explains why this happens with AI builders.

7. Check who on your team can see secrets. Bolt limits the Secrets tab to the project owner on individual accounts, and to owners, co-owners and admins on team accounts. If you've invited a freelancer as an admin and they've finished, change their role.

Part 3: Money and misuse (checks 8 to 10)

8. Try to skip the payment. If your app charges, start a checkout, then instead of paying, type the "success" or "thank you" page address straight into the browser. If that unlocks the paid feature, your app is trusting the browser. The unlock should happen only when your payment provider confirms the payment to your server, for example through a Stripe webhook.

9. Try to change a price or a limit. Open developer tools, go to the Network tab, and add something to the cart or use a credit. Look at the request your app sends. If it includes a price, a quantity limit or a plan name that the server simply accepts, someone can edit it. Prices and limits should be looked up on the server.

10. Try the one-time things twice. Coupons, free trials, invite codes and referral rewards are all "once only" rules. Try each one twice, from two accounts and from the same account. Bolt's audit looks for this kind of misuse, but only you know which things in your app are meant to be single-use.

Part 4: Launch basics (checks 11 and 12)

11. Test on the real domain, not the preview. Sign-up emails, password resets and Google sign-in often point at the preview address. Sign up with a new email on your live link and follow every email to the end. Make sure each link lands on your real domain.

12. Make a backup and know how to restore it. Find out where your data is backed up and how you'd get it back if a fix went wrong. Bolt keeps version history for your project, and its docs note that going back to a version from before a security fix also removes that fix. Version history covers your project. Your customer data needs its own backup plan, and you should know how to restore it before you need to.

How to read your results

• All 12 pass: you're in good shape for a first group of customers. Run Bolt's audit again after every big change. "Security audit up to date" only describes the project as it was when the audit ran.
• Any fail in checks 3, 4, 6 or 8: stop and fix it before more people sign up. These are the ones that leak customer data or give away paid features.
• Lots of "not sure": that's normal for a non-technical founder, and it's the best reason to get a second pair of eyes.

When you ask Bolt to fix something, describe the rule in plain words, for example: "Only the person who created an order can see or change it. Signed-out visitors can't see any orders." Then run the two-account test again. A fix you haven't re-tested isn't a fix yet.

What this checklist doesn't cover

These checks find the most common, most expensive mistakes. They don't replace a full review of your code, load testing, or a check of every outside service you've connected. If your app stores health, financial or children's data, the bar is higher and you should get a professional review before launch.

FAQ

Is a Bolt app secure by default?

Bolt turns on RLS for the tables it creates and offers built-in audits, which is a good start. But if you added sign-in late, added tables yourself, or asked for "public" access while testing, the rules may be more open than you think. Test it with two accounts.

Bolt's audit says everything is fixed. Do I still need these checks?

Yes, for the checks that depend on your business rules: who belongs to which team, what counts as paid, and what can only happen once. Bolt's audit can only check rules it knows about.

Will running the audit break my app?

Fixes change your code or database, so something you liked can change. Bolt's version history lets you go back, but going back also undoes the security fix. Test the main paths after each audit.

Get a second pair of eyes

If any check failed, or you ticked "not sure" more than twice, book a free technical assessment. We'll look at your Bolt app with you and tell you plainly what's safe and what isn't. See what our Bolt app security audit covers, then book a time that suits you.