Is my Lovable app safe?
Short answer: you cannot tell by using it. An app with a wide open database looks identical to a locked down one in the browser. The honest way to answer the question is to check the live app, so that is what this page does.
Check your Lovable app now
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.
Why you cannot see these problems yourself
The dangerous issues live in places you never look while building: the raw requests your app makes to its database, the keys buried in the JavaScript bundle, and the headers your server sends. All of that is invisible in the normal app view.
An attacker does not use your app the normal way. They open the network tab, read the shipped code, and send direct requests to your database. The scan below does the harmless version of that and tells you what they would find.
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
My Lovable app has no login. Does it still need security?
Yes, and often more. If your app stores anything in a database (form entries, sign ups, messages) that data can be readable even without a login screen, because the protection is on the database, not the page. The scan checks exactly this.
What is the most common Lovable security mistake?
A Supabase database with Row Level Security off. It means any anonymous request can read your tables. It is the single most common serious issue in AI-built apps, and the scanner checks for it directly.