Supabase RLS checker
Row Level Security (RLS) is what stops strangers from reading your Supabase tables. This tool checks whether it is actually working on your live app by doing the one test that matters: an anonymous read of your tables.
Check your Supabase tables
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 xlogs runs this check on your app
- We observeSupabaseA Supabase URL or key in the served code
- So we run a check we otherwise would notFinding a Supabase connection is what makes the database check run at all. Without it there is no database for us to ask anything of.
- And you geta result with the evidence behind it, a fix written for your coding tool, and a way to confirm it worked
Nothing about Supabase is a problem by itself. Observing it is what makes this check relevant; the result comes from the check, not from the detection.
What this checker does
It finds the public Supabase URL and anon key your app already ships, asks your database which tables it can list, then does one read per table as a logged-out user. Any table that returns real rows to that anonymous request is not protected.
It reports the table name, its column names, and an approximate row count as proof. It never stores the row contents, because the point is to warn you, not to copy your data.
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
What is RLS in Supabase?
Row Level Security is a Postgres feature that decides, row by row, who is allowed to read or change data. In Supabase you turn it on per table and add policies (for example, a user can read only their own rows). Until you do, a table with RLS off is readable by anyone with the public key.
Will enabling RLS lock my own app out of its data?
Only if you enable it without policies, so add the policies at the same time. A common pattern is: enable RLS, then add a policy allowing authenticated users to read their own rows, and keep any genuinely public tables public on purpose. Then re-run this check to confirm private tables no longer leak.
Can I check RLS without giving you credentials?
Yes. The checker only uses the public URL and anon key your app already ships to every browser. You never hand over a password or a service key.