Supabase Security Advisor vs xlogs
Supabase ships a Security Advisor in its own dashboard, and it is good. It is not competing with xlogs, because the two answer different questions. The Advisor reviews your configuration from inside your project. xlogs tests your live app from outside, as a stranger with no login. You want both.
Test it from the outside
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.
Inside view versus outside view
The Supabase Security Advisor runs inside your dashboard with project access. It reads your configuration and reports issues such as RLS disabled or missing policies, overly permissive rules, exposed auth tables, privilege escalation through SECURITY DEFINER functions, and GraphQL introspection exposure. Several of those are things xlogs cannot see at all, because they are only visible from inside the project.
xlogs never logs in. It finds the public Supabase URL and anon key your app already ships to every browser, then asks your tables for data as an anonymous stranger would. If rows come back, that is not a configuration opinion, it is a demonstration.
Both are worth running. The Advisor catches more classes of problem inside the database. xlogs proves what the outside world can actually reach, including cases where the app ships a key or setting that the database config alone would not reveal.
| xlogs | Supabase Security Advisor | |
|---|---|---|
| Where it runs | From outside, on your live URL | Inside the Supabase dashboard |
| Access needed | None. No login, no project access | Your Supabase project |
| How it judges RLS | Sends an anonymous read and reports what came back | Reviews your policies and configuration |
| SECURITY DEFINER, GraphQL introspection, auth tables | Not visible from outside | Yes, and this is a real advantage |
| Secrets in your shipped JavaScript | Yes | Out of scope |
| Works after you leave Supabase's dashboard | Yes, on any host | Supabase projects only |
| Price | Free | Included with Supabase |
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
If the Supabase Advisor says I am fine, do I need xlogs?
Yes, because the two can disagree, and that is the point. The Advisor reviews the database's own configuration. xlogs tests what your deployed app actually exposes, which also covers keys shipped in your frontend and settings applied outside the database. A clean Advisor plus a clean anonymous read from outside is a much stronger position than either alone.
Does xlogs need my Supabase credentials?
No. It only uses the public anon key your app already sends to every visitor's browser. There is nothing to connect and no password to hand over.