Supabase RLS: is your database public? (and how to lock it down)
With Row Level Security off, your public anon key can read your whole database. Here's how to check, and how to lock it down.
Updated June 19, 2026 · 5 min read
Check your own app in 30 seconds — free, no login:
Passive scan of your app's public files only — no login, nothing stored, your code never leaves your machine. Scan only apps you own.
How the leak happens
Supabase gives your frontend a project URL and a public 'anon' key so it can talk to the database. That's by design. Security is supposed to come from Row Level Security (RLS) — per-table rules that decide which rows each user can see.
The problem: AI tools frequently create tables without enabling RLS, or with RLS on but no real policies. When that happens, the public anon key — which is in everyone's browser — can read and often write every row in the table. In early 2026 a single breach of this kind exposed 18,000 users across 170+ AI-built databases.
How to check
In the Supabase dashboard, open Authentication → Policies (or the Table Editor). Any table showing 'RLS disabled' is wide open. Tables with RLS enabled but zero policies are also effectively locked to nobody OR open depending on configuration — you want RLS on AND explicit policies.
A faster gut-check: VibeShield detects a Supabase backend on your live app and flags it for review, so you know to verify RLS before you ship.
How to lock it down
Enable RLS on every table that holds user data. Then add policies that scope rows to their owner — typically comparing the row's user_id to auth.uid(). For example, a 'select' policy: using (auth.uid() = user_id).
Test it: query the table using only the anon key (logged out). You should get back nothing you don't own. If you still see other users' data, your policies aren't doing their job.
Don't paper over it with the service_role key on the client — that bypasses RLS entirely and is the worst-case leak. The service_role key belongs only on your server.
Frequently asked questions
- If I enable RLS, will my app break?
- It can — any query that relied on open access will now return nothing until you add a matching policy. That's expected. Add policies table by table and test as you go.
- Is the anon key itself a vulnerability?
- No. The anon key is meant to be public. The vulnerability is missing RLS policies behind it.
Don't guess — scan it
VibeShield checks your live app for exposed keys and open databases in about 30 seconds, and hands you the fixes.
Passive scan of your app's public files only — no login, nothing stored, your code never leaves your machine. Scan only apps you own.