Row Level Security (RLS) en Supabase: protege tus tablas

Ejecuta esto en el editor SQL de Supabase para listar todas las tablas del esquema public expuesto que todavía tienen RLS desactivado. El Security Advisor del dashboard reporta el mismo problema como "RLS disabled in public".

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

Activa RLS en cada tabla y luego agrega una política por operación. Limita las políticas al rol authenticated y compara la columna de propietario de la fila con auth.uid(). Los INSERT y UPDATE necesitan with check para que los usuarios no puedan escribir filas que pertenecen a otra persona.

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);

Sustituye las políticas provisionales como using (true) por condiciones reales. No bases la autorización en user_metadata — los usuarios pueden editarlo ellos mismos; usa app_metadata o una tabla de roles. Las vistas se saltan RLS salvo que se creen con security_invoker = true, y los buckets de storage necesitan sus propias políticas sobre storage.objects.

Consulta tu API exactamente como lo haría un atacante: solo con la clave pública y sin sesión de usuario. Si esto devuelve filas que no deberían ser públicas, tus políticas son demasiado abiertas.

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

Usa la service_role key (sb_secret_) solo en código de servidor, como rutas de API o Edge Functions, nunca detrás de un prefijo NEXT_PUBLIC_ o VITE_. Si alguna vez llegó al navegador, rótala desde el dashboard.