Lovable and Supabase security
Most Lovable apps store their data in Supabase. Supabase is secure only once Row Level Security is on and every table has a policy. That step is easy to miss, and when it is missed, anyone can read your data. This page checks it on your live app.
Scan your Lovable + Supabase 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.
How the Lovable and Supabase combination goes wrong
Lovable connects your app to Supabase and ships a public key so the frontend can read and write data. That public key is fine on its own. It becomes a problem when the tables behind it have no access rules, because then the key lets anyone (not just your users) read everything.
This is not a bug in either tool. It is a setting that has to be turned on per table. The scan finds your public Supabase URL and key in your app, then asks the database, as an anonymous user, whether it returns rows it should not.
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
Is it safe to expose the Supabase anon key in a Lovable app?
Yes, the anon key is meant to be public and ship in the browser. It is safe only when your tables have Row Level Security policies. Without them, that public key becomes a key to your whole database. The scan tells you which case you are in.
How do I know if Row Level Security is on?
The reliable way is to test it from the outside. The scanner sends an anonymous read to your tables. If real rows come back, RLS is not protecting that table. If nothing comes back, it is doing its job.