Supabase RLS Disabled: How to Check and Fix It (2026)

If Row Level Security (RLS) is off on a Supabase table, anyone who has your project's public anon key can read, change or delete that table's data. That key ships inside your frontend, so assume everyone has it.

This guide shows how to check whether you're affected and how to fix it.

Why it's dangerous

Supabase exposes your public schema through an automatic REST API. RLS is the rule layer that decides which rows each user may see or change. With RLS off, there are no rules, so the API answers anyone who asks.

A typical result: a stranger opens your site, copies the anon key from the browser's network tab, and downloads your whole users table.

How to check

1. Dashboard. Open Table Editor. Tables without RLS show an "RLS disabled" label. The Security Advisor (under Advisors) also lists them.

2. SQL. Run this in the SQL Editor to list every table and its RLS status:

1select schemaname, tablename, rowsecurity2from pg_tables3where schemaname = 'public';

Any row with rowsecurity = false is open.

3. Test it like an attacker. Request a table using only your public key:

1curl "https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*" \2  -H "apikey: YOUR_ANON_KEY" \3  -H "Authorization: Bearer YOUR_ANON_KEY"

If you get rows back and the table shouldn't be public, you have a problem.

How to fix it

Step 1: turn RLS on.

1alter table public.todos enable row level security;

With RLS on and no policies, nobody can read or write through the API. That's safe but locked, so you now add policies.

Step 2: add a policy for what users should be allowed to do. For example, let signed-in users read and edit only their own rows:

1create policy "Users read own rows"2on public.todos for select3to authenticated4using ((select auth.uid()) = user_id);5 6create policy "Users insert own rows"7on public.todos for insert8to authenticated9with check ((select auth.uid()) = user_id);10 11create policy "Users update own rows"12on public.todos for update13to authenticated14using ((select auth.uid()) = user_id);

Adjust the column name (user_id) to match your table.

Step 3: repeat for every table in public, then run the check query again.

Mistakes people make after enabling RLS

• Policies that allow everything. using (true) on a table with private data is the same as having no RLS.
• Using the service_role key in the frontend. It bypasses RLS completely. It belongs only on a server, never in browser code.
• Forgetting views. Views can bypass RLS depending on how they were created. On Postgres 15+, create them with security_invoker = true.
• Forgetting Storage. Buckets have their own policies. Check them too.
• Tables created later. Tables made with raw SQL don't get RLS automatically. Check again after every migration.

Quick checklist

• RLS enabled on every table in public
• Every table has policies that match who should access it
• No using (true) on private data
• service_role key is not in any frontend code or repo
• Storage bucket policies reviewed
• Re-checked after the latest migration

Check your whole repo automatically

Manual checks are easy to forget as the app grows. SetRepo scans your repo for disabled RLS, exposed keys, secrets in git history and other common security mistakes, and tells you how to fix each one.

Built with Lovable or Base44? Those apps often run on Supabase. See what to check in Lovable apps and Base44 apps.

Run a free scan →

FAQ

Is the Supabase anon key supposed to be public?

Yes. It's designed to be in your frontend. That's exactly why RLS must be on: the anon key is only safe when RLS limits what it can do.

What happens if I enable RLS without adding policies?

All access through the API is denied. Add policies for the access your app needs.

Does RLS apply to the service_role key?

No. The service_role key bypasses RLS, so keep it server-side only.

How often should I check?

After every migration that adds a table, and before every launch.