Is your Supabase data open to anyone?
This free check reads your own Supabase project the way a stranger would: with the public anon key and no login. It lists the tables your REST API exposes and shows which ones hand back rows without auth. It runs in your browser. Your URL and key never touch DappaSol.
Why this matters
Every Supabase app ships its anon key to the browser. That is by design: the key is public, and Row Level Security is the actual lock. If RLS is off on a table, or a policy says using (true), anyone who opens your site's JavaScript can copy the key and read that table with one request. No hacking skills involved. AI builders like Lovable and Bolt create tables fast, and the policies do not always keep up. We see it in nearly every vibe-coded app that lands on our desk.
How the check works
- It asks your REST endpoint (
/rest/v1/) which tables and views it exposes, using only the key you pasted. - For each table it requests one row with the anon key, no user session.
- It reports what came back: rows, nothing, or a refusal. It never displays the data itself, only whether data was returned and how many columns it had.
If your API refuses to list its tables, that is good hygiene, and you can type table names in by hand.
What the results mean
| Result | What it means | What to do |
|---|---|---|
| Open: rows returned | Anyone with your public key can read this table without logging in. | Fix now unless the data is meant to be public, like a product catalogue. |
| No rows returned | RLS is on and hides every row from anonymous users, or the table is empty. The check cannot tell which. | If the table has data, you are fine for reads. Still review insert, update and delete policies. |
| Blocked | The anon role has no permission on this table at all. | Nothing to do for anonymous reads. |
Honest limits: this tests anonymous reads only. A table can block reads and still accept anonymous inserts or updates, a logged-in user can often read other users' rows when a policy is too loose, and storage buckets and RPC functions have their own rules. A clean result here is a good start, not a security audit.
How to fix an open table with RLS
Two steps. Turn RLS on, then write the narrowest policy that lets your app work:
-- 1. lock the table (blocks the anon key until a policy allows access) alter table public.profiles enable row level security; -- 2. let signed-in users read only their own rows create policy "owners read own rows" on public.profiles for select to authenticated using ((select auth.uid()) = user_id); -- same idea for writes create policy "owners update own rows" on public.profiles for update to authenticated using ((select auth.uid()) = user_id) with check ((select auth.uid()) = user_id);
Then run this check again. Avoid policies with using (true) on anything private, and keep the service_role key on the server, never in client code or a public repo. Supabase's own guides are the reference: Row Level Security, Securing your API and API keys. Our longer walk-through is Supabase RLS hardening for Lovable and Bolt apps.
Built it in Lovable?
Start with is my Lovable app secure for the five places these apps usually leak. If the list of open tables is long, or you would rather someone senior fixed it properly, that is what Fix my Lovable app is for. Or message Ishan on WhatsApp or at ishan@dappasol.com. Free first look, no pitch deck.
Supabase RLS questions, answered
Is it safe to paste my Supabase anon key here?
Yes. The anon or publishable key is public by design and already ships inside your app's JavaScript, so anyone visiting your site can read it. This page sends it only to your own Supabase project, straight from your browser. Nothing goes to DappaSol and nothing is saved. Never paste the service_role or sb_secret_ key; the tool refuses those.
What does it mean if a table shows rows without login?
Anyone who copies your public key from your site can read that table with one request, no account needed. Either Row Level Security is off on that table, or a policy allows anonymous reads. Fine for a public product catalogue, a real problem for profiles, orders, messages or anything personal.
Does a clean result mean my Supabase app is secure?
No. It means anonymous users cannot read the tables tested. Writes are not tested, logged-in users may still read other users' rows through loose policies, and storage buckets, RPC functions and edge functions have their own rules. Treat it as a first check, not an audit.
How do I turn on Row Level Security in Supabase?
Run alter table public.your_table enable row level security; in the SQL editor, then add a policy for each action your app needs, for example a select policy for authenticated users using ((select auth.uid()) = user_id). RLS on with no policy blocks everything, which is safe but will break the feature until the policy exists.
Why does my API not list any tables?
Some projects do not expose the schema to the anon key, or have revoked anon access to the public schema. Both are good signs. You can still type specific table names into the optional field and test them one by one.
Can I use this on someone else's app?
No. Only test projects you own or have written permission to test. The checkbox is there for a reason. If you think another product is leaking data, tell its owner privately so they can fix it.