Guide Bolt
Is my Bolt app secure?
Short answer
You can't tell from how a Bolt app looks. It is secure enough to launch when a stranger can't read or change other people's data and no secret key ships to the browser. Check four things before you publish: run Bolt's security audit from the Publish menu (it doesn't use tokens, paid plans), fix every Error on the database Security tab (all plans; it uses the same checks as Supabase's Security Advisor), test with a second account that it can't see the first account's data, and make sure no secret key sits in a VITE_ variable or your code.
1. Run Bolt's security audit
In your project, click Publish, then Run security audit. Bolt says it reviews "your whole project, including your code and database", fixes what it can and lists anything you must do yourself under "Needs your action". Bolt recommends the Publish-menu button because prompting Bolt to audit in chat uses tokens. The audit is on paid plans and you can run up to 30 per day.
2. Read the database Security tab
Click the database icon at the top of the screen, then Security. This page is on all plans and checks only your database. Bolt says it "uses the same database checks as the Security Advisor in Supabase."
The warning to take seriously is RLS Policy Always True: a policy with no conditions, so any visitor can view, add, change or delete that table. Bolt notes it may write these policies if your site has no sign-in. That's fine for a public menu; it's not fine for orders, messages or anything personal. For private data, add sign-in and ask Bolt to limit each policy to the signed-in user's own rows.
3. Test with two accounts
- Sign up as test users A and B.
- As A, create something private (an order, a note).
- Sign in as B and try to open A's item, including by changing an id in the URL.
- Sign out and try again.
If B or a signed-out visitor can see A's data, your policies are too open. Scanners read code and settings; this test shows what a real user can reach.
4. Look for secret keys in the browser
Anything in a VITE_ variable is bundled into the JavaScript every visitor downloads. The Supabase anon or publishable key is meant to be public. A service_role key, an sb_secret_ key, or a Stripe/OpenAI secret key is not: move it to server-side code (Bolt stores secrets for its server functions) and rotate it. Bolt's audit also checks that private keys aren't in your code or sent to browsers. More: Is my Supabase anon key exposed?
Where we can help
Free instant check: paste your URL at patchandship.com/check.html to scan your homepage's JavaScript for secret keys and security headers (no signup, nothing stored). Paid, fixed price per app: Database Check, $49; Security Fix, $149 (every critical issue on our checklist fixed within 48 hours of working access); Fix & Deploy, $249. Otherwise a full refund if you ask within 14 days of purchase (Refund Policy). AI agents run the checks and a human engineer approves every change. Not a penetration test or a security guarantee.
FAQ
Is a Bolt app secure by default?
Partly. Bolt turns on RLS for the tables it creates, but it may write open policies when your site has no sign-in, and tables you add yourself need RLS turned on. Run the audit and check the Security tab before launch.
Is Bolt's security audit free?
Bolt says the audit and its fixes don't use your tokens, but the project audit is on paid plans. The database Security tab is available on all plans.
Is it OK that my Supabase anon key is in my Bolt app?
Yes. The anon and publishable keys are designed to be public. Your data is protected by RLS policies, not by hiding that key. Secret and service_role keys must never be in the frontend.
What does 'RLS Policy Always True' mean?
A policy has no condition limiting who can access a row, so every visitor can use it. Acceptable only for data you're happy for anyone to change; otherwise restrict it.
Does a clean audit mean my app can't be hacked?
No. It's a strong signal, not a guarantee. Bolt fixes what it finds; the two-account test checks real behavior.