¿Qué es Row Level Security (RLS) y cómo protege cada fila de PostgreSQL?
Publicado el 2026-10-20 por frfrand
RLS explicado con un ejemplo de pedidos y usuarios: políticas por fila, permisos SQL, auth.uid(), service role y errores de seguridad frecuentes.
Row Level Security (RLS) es una función de PostgreSQL que permite definir qué filas de una tabla puede leer o modificar una cuenta según políticas de acceso. Es especialmente útil cuando una aplicación guarda datos de muchos usuarios o empresas en las mismas tablas.
Imaginá una tabla con pedidos de mil clientes. Todos pueden utilizar la misma aplicación, pero ninguno debería ver las compras de otra persona. RLS permite aplicar parte de esa separación directamente donde viven los datos.
El ejemplo de los armarios
Pensá en un edificio con un depósito común. Cada cliente tiene un compartimiento identificado. La puerta principal permite entrar al edificio, pero eso no significa que puedas abrir cualquier armario.
En una base relacional, los permisos sobre la tabla se parecen al acceso general al depósito. Las políticas RLS comprueban qué filas corresponden a cada identidad y operación.
La metáfora no es perfecta, pero ayuda a distinguir permiso para consultar una tabla y permiso para consultar una fila concreta.
¿RLS reemplaza los permisos normales?
No. PostgreSQL utiliza privilegios sobre objetos y políticas sobre filas. Ambas capas importan.
Si una cuenta no tiene permiso para ejecutar SELECT sobre una tabla, agregar una política RLS no le concede automáticamente ese privilegio. Y si una cuenta tiene privilegios amplios o puede saltarse RLS, tampoco conviene asumir que una política la restringirá.
En Supabase es especialmente importante revisar qué roles tienen permisos sobre las tablas expuestas y qué políticas se aplican.
Un ejemplo con una aplicación de turnos
Supongamos que tienes una tabla reservas con campos id, usuario_id, fecha y estado.
Querés que cada persona consulte sus reservas, pero no las de otros usuarios. Una política de lectura puede comparar el identificador del usuario autenticado con el campo usuario_id de cada fila.
El mecanismo específico depende de cómo llegue la identidad a la base. En Supabase, por ejemplo, se utilizan funciones como auth.uid() dentro de las políticas.
La idea es que la base de datos filtre las filas autorizadas, incluso cuando una petición intenta consultar más información de la debida.
¿Y para actualizar o insertar información?
Las políticas pueden distinguir operaciones. Permitir leer una reserva propia no significa permitir cambiar su importe, aprobarla en nombre de un administrador o crearla para cualquier usuario.
Hay que definir reglas para SELECT, INSERT, UPDATE y DELETE según el modelo de acceso.
También conviene evitar que una persona cambie el propietario de una fila para conseguir acceso posterior. El diseño debe contemplar tanto las filas existentes como los valores nuevos.
¿RLS significa que ya puedo confiar en el frontend?
No. La interfaz sigue necesitando un diseño correcto, y el servidor debe realizar comprobaciones adicionales cuando corresponda.
RLS protege operaciones sobre filas dentro de PostgreSQL bajo sus reglas; no valida automáticamente pagos, envíos de correo o decisiones complejas de negocio.
Es una capa de defensa particularmente valiosa cuando existen APIs o SDK que permiten acceder a determinadas tablas desde clientes autenticados.
¿Qué es service_role en Supabase?
Supabase utiliza un rol de servicio con privilegios elevados que puede omitir las políticas RLS. Por esa razón, las claves de servicio deben permanecer del lado del servidor y bajo controles de acceso apropiados.
No es seguro colocar una credencial con capacidad de saltarse las políticas dentro del JavaScript público de una web.
Tampoco confundas una clave publicable del proyecto con autorización universal: el acceso efectivo depende de roles, políticas y configuración.
Errores frecuentes
Crear la tabla y olvidarse de las políticas. Algunas configuraciones exponen datos si los privilegios lo permiten.
Aplicar solo una política de lectura. Insertar o actualizar filas puede requerir reglas distintas.
Probar únicamente con un administrador. Si esa cuenta evita RLS, podrías pensar que todo funciona y descubrir después que los usuarios reales no pueden acceder o acceden indebidamente.
No comprobar casos negativos. Las pruebas deben confirmar que el cliente A no puede leer ni modificar filas del cliente B.
¿Cómo encaja en ArduMaker?
Si desplegás una base PostgreSQL en un VPS administrado desde ArduMaker, podés utilizar capacidades de seguridad propias del motor, incluido RLS cuando resulte apropiado. Pero configurar el servidor no define automáticamente las políticas de tu aplicación: eso pertenece al diseño de datos y permisos.
En resumen: RLS ayuda a controlar el acceso fila por fila. Combinado con permisos SQL, autenticación y pruebas, puede ser una defensa importante para aplicaciones multiusuario.
Fuentes: RLS en PostgreSQL · RLS en Supabase · Para qué sirve Supabase.