Supabase vs Firebase security
Supabase and Firebase are the two databases most AI-built apps reach for, and they fail the same way: both are readable until you write the rules that lock them down. They just use different mechanisms. Here is how each controls access, the mistake that leaves each one open, and a live check for your app.
Scan your 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 each one controls access
Supabase is Postgres. You protect a table by turning on Row Level Security and writing policies that say who can read or change which rows. Until you do, the table is readable by anyone with the public key your app ships.
Firebase protects data with Security Rules. You write rules per collection that say who can read or write. New projects often start in test mode, where the rule effectively allows anyone, and that setting quietly ships to production.
The mistake that leaves each one open
On Supabase, it is leaving Row Level Security off. On Firebase, it is leaving the rules in test mode (allow read, write: if true). Different words, same result: a stranger with your public config can read your data.
Neither tool is less safe than the other in principle. The risk is the same human step, writing the access rules, being skipped because the app works fine without it.
| Supabase | Firebase | |
|---|---|---|
| Data model | Postgres (SQL tables) | Firestore / Realtime DB (documents) |
| Access control | Row Level Security policies, per table | Security Rules, per collection or path |
| The common mistake | RLS left off, table world-readable | Rules left in test mode (if true) |
| How to check it | Send an anonymous read; if rows come back, it is open | Review your Security Rules in the Firebase console or emulator |
| Can xlogs verify it live? | Yes, with an anonymous read of your tables | No; xlogs checks your keys, headers and source, but Firebase rules are checked in Firebase |
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 Supabase or Firebase more secure?
Neither is inherently safer. Both are open until you write access rules (Supabase RLS policies, Firebase Security Rules), and both let you build a fully locked-down app. The real risk is skipping that step, which is equally easy on either.
Can xlogs check my Firebase rules?
Not directly. xlogs scans your live app for exposed keys, missing headers, and source exposure regardless of your backend, and it tests Supabase tables with an anonymous read. Firebase Security Rules are evaluated inside Firebase (the console or the local emulator), so check them there.