Supabase Row Level Security (RLS): proteggi le tue tabelle

Esegui questa query nel SQL editor di Supabase per elencare ogni tabella dello schema public esposto che ha ancora la RLS disattivata. Il Security Advisor nella dashboard segnala lo stesso problema come "RLS disabled in public".

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

Attiva la RLS su ogni tabella, poi aggiungi una policy per ciascuna operazione. Limita le policy al ruolo authenticated e confronta la colonna del proprietario della riga con auth.uid(). Insert e update richiedono with check, così gli utenti non possono scrivere righe che appartengono ad altri.

alter table public.profiles enable row level security;

create policy "Users read own profile"
  on public.profiles for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Users update own profile"
  on public.profiles for update
  to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Sostituisci le policy segnaposto come using (true) con condizioni reali. Non basare l'autorizzazione su user_metadata, che gli utenti possono modificare da soli: usa invece app_metadata o una tabella dei ruoli. Le view scavalcano la RLS a meno che non siano create con security_invoker = true, e i bucket di storage richiedono policy proprie su storage.objects.

Interroga la tua API esattamente come farebbe un malintenzionato: solo con la chiave pubblica e senza alcuna sessione utente. Se la richiesta restituisce righe che non dovrebbero essere pubbliche, le tue policy sono troppo aperte.

curl "https://<project>.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <anon-key>"

Usa la chiave service_role (sb_secret_) solo nel codice server, come route API o Edge Functions, mai dietro un prefisso NEXT_PUBLIC_ o VITE_. Se è mai arrivata al browser, ruotala dalla dashboard.