Built with Bolt
Bolt ships the app. The rules on your data are yours.
Bolt gives you a place to put secrets and a screen that flags database problems. Both wait for you to open them.
Every claim below is Bolt’s own help centre, linked to the page it came from. The platform is not the problem here; the question is who opens the screens it fills in.
Bolt is a trademark of its owner. This page quotes public documentation to explain a scope of work. There is no partnership, endorsement or affiliation in either direction.
What stays yours
Bolt flags it. Somebody has to look.
The platform scaffolds the database, stores your secrets and deploys the result. These four decisions it leaves on your desk.
Opening the Security Audit screen
Bolt puts what it finds in one place: “Any database security issues Bolt identifies appear on the Security Audit page.” A finding sitting there unread protects nothing.
The policy that is always true
A rule can exist and still let everyone through — “the RLS Policy Always True warning shows”. It reads as protected while behaving like an open table.
Putting the key in Secrets rather than in code
The safe route, in Bolt’s words: a server function “can securely read the secret and complete its task”, so it “ensures that private information never ends up in your users’ browsers or devices”. A key in a component skipped it.
Deciding what a fix prompt actually changed
Bolt can remove and re-add row-level rules when you ask it to. That is fast, and it means the shape of the rule protecting your customers was settled in a chat message that nobody re-read afterwards.
Check it tonight
Four screens, twenty minutes.
Bolt has already done some of this work for you. The first check is opening the page where it put the answer.
Open the Security Audit page and read every row
It is the one screen Bolt fills in for you. Anything listed there is a finding the platform already made and is waiting for a person to act on.
Look for a rule that lets everyone through
In your table list, find any policy whose condition is always true. It counts as a policy and stops nobody, which is why it survives a glance at the dashboard.
Search your published page for a key
Load the deployed app, open what the browser downloaded, and look for anything shaped like a credential — service_role, sk_live, a long random string. If it arrived at a visitor’s machine, it is theirs.
Load one of your records without signing in
Copy the address of a record you own and open it in a private window. If it renders, the thing keeping other people out was a screen, and screens are not where that rule belongs.
A finding on that screen is Bolt telling you something, free, today. The five-flaw prompt covers ground no dashboard does.
What a read adds
A screen shows what a screen can see.
The four above catch a published key and a rule that lets everyone through. They cannot tell you that a policy is correct for signed-in users but wrong for the one endpoint that runs without a session, or that a server function trusts an id the browser handed it.
Those come from reading the code rather than a dashboard, which is the audit. Its scope is published in full, including where it stops.
€350 + VAT · 48 hours
An independent pass over your app.
Your repository and your live app, every finding with the evidence, what it costs you and a prompt you can paste back into Bolt.
€430.50 including VAT.
Start here
Let the fit check decide.
Five questions about what you built. If a Bolt app this size does not need an audit yet, that is what comes back.