Supabase RLS con ejemplos: cómo impedir que un usuario vea datos ajenos

Publicado el 2026-10-26 por frfrand

Políticas RLS prácticas con auth.uid y pruebas de permisos

Supabase RLS con ejemplos: cómo impedir que un usuario vea datos ajenos

Tienes una tabla de notas con user_id. Si la API devuelve todas las notas y el frontend solo filtra las propias, cualquier usuario curioso puede solicitar datos ajenos. Row Level Security permite aplicar políticas en PostgreSQL para restringir filas.

La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.

Qué hace RLS de Supabase en la práctica

Supabase usa PostgreSQL y su integración de autenticación puede exponer el identificador del usuario mediante auth.uid() en el contexto correcto. RLS requiere habilitarse en cada tabla expuesta y definir políticas para SELECT, INSERT, UPDATE y DELETE que correspondan.

No alcanza con repetir una receta si no entiendes quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.

Un ejemplo concreto

ALTER TABLE public.notas ENABLE ROW LEVEL SECURITY;

CREATE POLICY "leer notas propias"
ON public.notas FOR SELECT TO authenticated
USING (user_id = (SELECT auth.uid()));

CREATE POLICY "crear notas propias"
ON public.notas FOR INSERT TO authenticated
WITH CHECK (user_id = (SELECT auth.uid()));

Los nombres, tablas y claves de este ejemplo son ilustrativos. Pruébalo primero en una base o entorno de ensayo y adapta permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.

Paso a paso

Agregá una columna propietaria user_id de tipo compatible con el identificador de Auth.
Habilitá RLS en la tabla expuesta y definí una política SELECT mínima.
Creá políticas de INSERT/UPDATE separadas que comprueben el propietario correcto.
Probá con dos usuarios distintos y uno no autenticado, no sólo con admin.
No expongas la service role key en el navegador: puede saltar controles de RLS.

Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.

Ejemplo de proyecto de trabajo

En una plataforma de clases, cada alumno ve sus reservas. Si el frontend recibe todos los registros y filtra por cliente, RLS podría evitar lecturas no autorizadas cuando la solicitud se hace con el rol y JWT adecuados.

Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.

El error típico

El rol service_role en Supabase suele eludir RLS; usarlo por accidente desde el cliente anula el modelo. Las políticas dependen del esquema y de permisos SQL: probá todas las operaciones con roles reales.

También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guardá una copia verificable o migración reversible y comprobá que la aplicación pueda seguir funcionando durante el cambio.

¿Cómo lo resolvería con ArduMaker?

Otra opción es una API Django o FastAPI y PostgreSQL en ArduMaker con autorización implementada en el backend. No es equivalente automáticamente a Supabase Auth + RLS: tendrías que diseñar y probar esas reglas.

ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.

Tres comprobaciones antes de publicar

Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?

Seguridad: ¿un usuario autenticado puede acceder sólo a su información, y la API utiliza una identidad de base con permisos mínimos?

Recuperación: ¿sabés restaurar los datos y revertir la versión de código compatible si una actualización sale mal?

Si podés responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando sólo miraste si el endpoint devolvía 200.

Recursos para profundizar

Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.