Supabase Row Level Security

What this check measures

If the audit detects Supabase usage (the anon key visible in JS), we attempt a `select *` from commonly named tables (users, profiles, posts) using the anon key. If data returns, RLS is missing — critical.

Why it matters

Without RLS, anyone with your anon key (which is in your JS) can run any query. We regularly audit Lovable apps where `select * from users` returns every customer's email from a browser tab. This is the #1 security issue we find.

Typical findings

• error_outlineusers table queryable by anon — email, hashed passwords, everything leaked.
• error_outlineRLS enabled but no policies — table is locked, but developer "fixes" by disabling RLS again.
• error_outlineservice_role key used in a client file — bypasses RLS entirely.

How to fix

Enable RLS on every table: `alter table X enable row level security;`. Add policies matching your access pattern (e.g., `using (auth.uid() = user_id)`). Test from incognito browser — no data should leak.

Frequently asked questions