Is your Bolt app actually secure?
Bolt turns a prompt into a working full-stack app in minutes, and most Bolt apps keep their data in Supabase. The settings that keep that data private are exactly the ones a fast build tends to skip. This page explains what breaks on Bolt and scans your live app now.
Scan your Bolt app
What it means
Your database tables can be read by anyone, not just logged-in users. Someone could open your app's data — customer emails, orders, private records — without ever creating an account.
Why AI tools cause it
Supabase only protects a table once you turn on Row Level Security (RLS) and write access rules for it. AI tools frequently build a working app without doing that, so the tables are wide open by default.
How xlogs checks it
xlogs finds your public Supabase URL and anon key in your app (the same ones your frontend uses), asks the database as an anonymous user which tables it can read, and flags any that return real rows. Read-only: it never writes or deletes.
What breaks most often on Bolt apps
The recurring issues on Bolt apps are the same three that hit most AI-built apps: a Supabase database left readable by anyone, a secret key shipped in the browser code, and missing security headers. Bolt gets the app running; these are settings it does not turn on for you.
None of them are visible while you use the app. It looks finished and works fine. The scan below checks your live app the way an outsider would.
The top Bolt security issues to check
- Publicly readable Supabase database (Row Level Security off)
- An API key or service key exposed in the client bundle
- Missing security headers (CSP, HSTS, X-Frame-Options)
- Source maps that let anyone download your original code
How to fix it
The goal: Row Level Security is enabled on every table, with policies so a table only returns rows to users allowed to see them; no table returns private data to an anonymous request.
- Enable Row Level Security (RLS) on every table, especially the affected spot
- Add a policy per table so only authenticated users can read/write their own rows (keep intentionally-public tables public on purpose)
- Re-check that an anonymous request no longer returns private rows
In my app (the spot the scan shows): anyone can read this database table. Please make this true: Row Level Security is enabled on every table, with policies so a table only returns rows to users allowed to see them; no table returns private data to an anonymous request. Steps: Enable Row Level Security (RLS) on every table, especially the spot the scan shows; Add a policy per table so only authenticated users can read/write their own rows (keep intentionally-public tables public on purpose); Re-check that an anonymous request no longer returns private rows. Then tell me exactly what you changed, and do not print any secret values back to me.
Then verify: After you deploy the policies, xlogs repeats the same anonymous read test and confirms the table no longer returns data without a login.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
Does Bolt make my app secure by default?
No. Bolt gets your app running, but it does not turn on database access rules or add security headers. Those decide who is allowed to read your data, and they have to be set on your project. A working Bolt app can still expose its whole database.
How do I check if my Bolt app is safe?
Paste your live Bolt URL into the scanner above. It reads the JavaScript your app ships, checks your response headers, and asks your database, as an anonymous user, whether it returns private rows. You get a plain-English report and a fix.