Supabase row-level security is off: how to fix it

By Shinobi Tech, the team behind AppLeakWatch. Updated .

With row-level security off, a table can be read through your public API using the key in your site's code. Turn it on for every public table, then add policies, because turning it on with no policy blocks normal access too.

Why this happens

AI tools often create tables quickly and move on to the feature you asked for. Your app still works, so nothing tells you the door was left open.

How to check

  1. Run this in the Supabase SQL editor:
    select tablename, rowsecurity
from pg_tables
where schemaname = 'public';
  2. Any row showing false is unprotected.
  3. A policy that uses (true) is on, but it may still let everyone read, so read your policies as well.

How to fix it

  1. Turn it on for each table:
    alter table public.profiles enable row level security;
  2. Add a rule for each action. This one assumes the table's id matches the user:
    create policy "Users read own profile"
on public.profiles for select
using (auth.uid() = id);
  3. Test as a signed-out visitor and as a second user.

Prompt for your AI tool

Check every table in the public schema. Enable row-level security on all of them. Write the smallest policies that keep the app working, so users can only reach their own rows, and explain each policy in one sentence.

Review what your AI tool changes, and test the live site afterward.

Catch this before a stranger does

AppLeakWatch keeps checking your live app and emails you when something new appears.

Start your 7-day trial

Common questions

Why did my app break after enabling RLS?

With no policy, all access through the public key is refused. Add a policy for each action your app needs.

Does RLS slow my app down?

A simple policy usually adds little. Index the columns your policies use, such as user_id.

Related guides