Leaking right now? Do these five things, in order.

Rotate

If a secret key is exposed, rotate it first.

A Supabase service role key (or a newer sb_secret_… key) ignores every access rule, so nothing else on this page helps until it is replaced. The same goes for payment and AI keys found in your code or git history. Deleting the key from the code is not enough: old commits keep it (PL-011).

Not sure whether a key is server-only? PL-010 shows how to tell in one command, locally.

Find

Find every table outsiders can read.

Paste this into the SQL editor of your Supabase project. It only reads the catalogue: it changes nothing. Tables with personal columns are listed first; start with those.

-- PatchLabs: which public tables can outsiders read? Read-only.
with personal as (
  select table_name::text as table_name,
         string_agg(column_name::text, ', ') as personal_columns
  from information_schema.columns
  where table_schema = 'public'
    and column_name ~* '(email|phone|mobile|whatsapp|address|birth|dob|passport|ssn)'
  group by table_name
),
tbl as (
  select c.relname::text as table_name, c.relrowsecurity as rls_on
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public' and c.relkind = 'r'
),
open_reads as (
  select tablename::text as table_name,
         string_agg(policyname || ' [' || array_to_string(roles, ',') || ']', '; ') as policies
  from pg_policies
  where schemaname = 'public'
    and cmd in ('SELECT', 'ALL')
    and (qual = 'true'
         or qual ilike '%auth.uid() is not null%'
         or qual ilike '%auth.role() = ''authenticated''%')
  group by tablename
)
select t.table_name,
       case when not t.rls_on then 'RLS is OFF'
            else 'Open read policy: ' || o.policies end as problem,
       coalesce(p.personal_columns, '-') as personal_columns
from tbl t
left join personal p using (table_name)
left join open_reads o using (table_name)
where not t.rls_on or o.policies is not null
order by (p.personal_columns is null), t.table_name;

RLS is OFF

No rules at all. If the API roles have access, the public key reads and writes everything (PL-008).

[anon] or [public]

Anyone on the internet can read every row (PL-001).

[authenticated]

Anyone who signs up can read every row (PL-002).

Some rows are meant to be public (products, opening hours, a shop’s own phone number). Focus on tables holding your users’ details.

Close

Close the worst table.

Pick the table with the most sensitive personal columns. First save its current rules, so you can see what you changed and undo it:

-- Replace profiles with your table name. Copy the output somewhere safe.
select policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public' and tablename = 'profiles';

Then choose one of two fixes.

-- Replace profiles, user_id and the policy name with yours (from step 2).
alter table public.profiles enable row level security;
drop policy if exists "Profiles are viewable by everyone" on public.profiles;
create policy "Owner reads own rows"
  on public.profiles for select
  to authenticated
  using ((select auth.uid()) = user_id);

-- Replace profiles with your table. Drops every read rule on it.
alter table public.profiles enable row level security;
do $$
declare p record;
begin
  for p in select policyname from pg_policies
           where schemaname = 'public' and tablename = 'profiles'
             and cmd in ('SELECT', 'ALL')
  loop
    execute format('drop policy %I on public.profiles', p.policyname);
  end loop;
end $$;

Check

Check it worked, as an outsider would.

Read the table as a logged-out visitor and as a brand-new user. Both run inside a transaction that is rolled back, so nothing changes.

-- Expect 0 from both. Replace profiles with your table.
begin;
set local role anon;
select count(*) as visitor_can_read from public.profiles;
set local role authenticated;
select set_config('request.jwt.claims',
  '{"sub":"00000000-0000-0000-0000-000000000000","role":"authenticated"}', true);
select count(*) as stranger_can_read from public.profiles;
rollback;

Then from outside, against your own project, with the public key from your app:

curl "https://<your-project-ref>.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: <your public anon key>"
# [] or a permission error: closed.  Any row: still open.

Finally, sign in to your app as a normal user and check the page that uses this table. If it broke, that is expected with option B; option A should keep it working.

Record

Look for access, write it down, decide who to tell.

• Look at your API logs. In the Supabase dashboard’s logs, filter requests to /rest/v1/<your table> and look for traffic you don’t recognise. How far back you can see depends on your plan.
• Write down what happened. Which tables and columns were open, since when (your migration history shows when the rule arrived), what you changed and when. You will need this record whatever you decide next.
• Decide who to tell. If personal data may have been accessed, you may have to report it. Under UK and EU GDPR, a notifiable breach goes to the regulator (the ICO in the UK) within 72 hours of you becoming aware of it, and people at high risk must be told. This is general information, not legal advice; take advice if you are unsure.