Bolt security audit tool: how to audit your Bolt.new app before you publish
Short answer: run Bolt's built-in checks, then run a free SniffPup scan (SniffPup is a free passive security scanner for vibe-coded apps) on your live URL. Bolt has two: the database security check (all plans) and the project security audit in the Publish menu (paid plans). Fix what they flag and test your data as a stranger. Only audit apps you own.
Home › Guides › Bolt security audit · Last updated · By Ember, SniffPup
Where SniffPup fits: Bolt's checks read your project and database from the inside. A free SniffPup scan reads your published site from the outside, passively, the way a stranger would: secret keys in your HTML and JavaScript (masked in the report), public /.env and /.git files, a public source map, security headers, cookies and HTTPS. No signup.
A 100 means no issues were found in our checks. It is never proof of security.
1. Run the database security check (all plans)
In your Bolt project, click the database icon at the top center, then Security. The page is titled "Security Audit" but, per Bolt's database security docs, it checks only your database: missing row-level security (RLS), policies that are too open, a mutable function search path, leaked-password protection turned off and similar. It uses the same checks as Supabase's Security Advisor, and labels each one Error, Warning or Info, most serious first. Click Ask Bolt to fix to have Bolt correct them, and open the page again after every database change.
2. Run the project security audit (paid plans)
Click Publish (top right), then Run security audit. Per Bolt's docs, it reviews your whole project, code and database, fixes most problems on its own and lists anything you need to do yourself under "Needs your action" in the chat. Use the button, not a chat prompt: the button doesn't use tokens, a prompt does. It checks:
- who can see and change your data (can one user touch another user's rows?)
- what your app makes public, like error messages that reveal whether an email has an account
- sign-in and sessions: protected pages need an account, sign-out ends the session, password and email-verification rules
- misuse, like changing a price, skipping a step or claiming a single-use item twice
- visitor input: file uploads, links your app opens for someone, and text shown back on a page
- keys and settings: private keys and passwords not in your code or sent to browsers, which sites can talk to your app
When it finishes, the button reads Security audit up to date. Expand the summary in the chat to see what changed. If a fix breaks something, Bolt's version history can take you back (that also removes the security change, so prefer describing the problem in the chat).
3. Decide what each table should allow
The warning to look for is RLS Policy Always True: a policy with no conditions. Bolt's docs say that if you haven't added sign-in, Bolt might write policies that let any visitor view, add, change and delete your data. For each table, pick one:
- View only (menus, blog posts, portfolios): visitors can read, not change.
- Submit only (contact forms, sign-ups, reviews): visitors can add rows but not read anyone else's.
- Private (orders, messages, accounts): add sign-in, then limit each row to its owner.
Then ask Bolt to update the policies to match. The RLS policy examples show what each pattern looks like.
4. Test like a stranger, then like another user
- Signed out: open your live site in a private window and watch the network requests to your database (DevTools, Network tab). Anything those requests return, any visitor can get. If your site uses a Supabase project URL and public key, the RLS checker guide has a one-line request to test a private table.
- Two users: sign up two test accounts and, as user B, try to open user A's pages or rows. If it works, a policy checks that someone is signed in but not that the data is theirs.
5. Keep private keys out of the browser
Anything in a VITE_ variable or your frontend code ships to every visitor. Store private keys in Bolt's secrets and call them from server-side code. A public Supabase anon or publishable key is fine to ship; a secret or service_role key is not. See is the Supabase anon key safe? If a private key already shipped, follow what to do after leaking an API key: rotate it first.
6. Scan what your published site shows a stranger
Bolt's checks look inside the project. Run a free SniffPup scan on your bolt.host address or custom domain to see what visitors can load: secret keys in your HTML and same-origin JavaScript, public /.env and /.git files and source maps, security headers, cookies and HTTPS, and, when your site ships a public Supabase key, a read-only check of up to 8 tables (no rows downloaded). For a hands-on version, see how to find exposed API keys on your website.
7. Repeat after every change
Re-run the database check after each database change and the project audit after new features (up to 30 audits a day, reset at midnight UTC), then re-scan the live URL after you publish. For the full pre-launch list, see the Bolt app security checklist.
FAQ
What is the best Bolt security audit tool?
Start with Bolt's own two checks. The project security audit (Publish menu, Run security audit) reviews your whole project, code and database, fixes what it can and lists anything you need to handle; Bolt's docs say it doesn't use your tokens when started from that button, and it's on paid plans. The database security check (database icon, then Security) is on all plans and uses the same checks as Supabase's Security Advisor. Neither looks at your published site from the outside, so pair them with an outside scan of your live URL, such as a free SniffPup scan.
Does asking Bolt in the chat to audit my app cost tokens?
Yes. Bolt's docs say to use the Run security audit button in the Publish menu, because that doesn't use tokens, while prompting Bolt to audit your project decreases your token balance. You can run up to 30 audits a day; the limit resets at midnight UTC.
What does the RLS Policy Always True warning mean in Bolt?
A database policy has no conditions, so it doesn't limit who can reach a row. Bolt's docs say that on a site without sign-in, Bolt may write policies that let any visitor view, add, change and delete data. It's only acceptable if you're fine with every visitor changing or deleting that data. Otherwise pick view-only, submit-only or private (with sign-in) for each table and ask Bolt to update the policies.
Can SniffPup audit my Bolt app?
From the outside, yes. A free SniffPup scan of your published URL (a bolt.host address or your own domain) checks what any visitor can load: secret keys in your HTML and JavaScript, public .env and .git files, source maps, security headers, cookies and HTTPS, plus a read-only check of whether your public Supabase key can read rows in up to 8 tables when your site ships one. It can't see your code or database policies, so run Bolt's checks too.
Does a clean SniffPup report mean my Bolt app is secure?
No. A score of 100 means no issues were found in our checks. It is never proof of security, and it says nothing about your server code, your database policies or what signed-in users can reach.
Sources: Bolt's Check your project's security and Database security settings help pages, checked October 28, 2026. Bolt changes quickly, so check their help center for the latest menus.
A score of 100 means no issues were found in our checks. It is not proof that your app is secure.