Seguridad con Row Level Security (RLS) en Supabase

Configuramos la seguridad con RLS en Supabase para que cada usuario acceda solo a los datos que le corresponden. Escribimos y probamos las políticas de cada tabla, revisamos el uso de las claves del proyecto y corregimos configuraciones que hoy dejan información expuesta a cualquiera que conozca la dirección de tu API.

Pedir presupuesto WhatsApp

Te respondemos con una propuesta concreta. Sin compromiso.

Qué es RLS y por qué es clave en Supabase

Row Level Security (RLS), o seguridad a nivel de fila, es una función de PostgreSQL que filtra las filas de una tabla según quién hace la consulta. En Supabase es la pieza central de la seguridad: el frontend consulta la base de forma directa con una clave pública, así que la base misma tiene que decidir qué devolver. Si una tabla expuesta no tiene RLS activado, cualquiera que tenga esa clave puede leerla o modificarla. Este trabajo forma parte de nuestro servicio de desarrollo con Supabase.

Señales de que tu proyecto tiene un problema de seguridad

El asesor de seguridad del panel de Supabase marca tablas sin RLS o funciones expuestas.
Hay políticas que permiten todo a cualquier usuario autenticado, sin distinguir de quién es cada fila.
La clave de servicio aparece en el código del frontend, en variables públicas o en el repositorio.
Un usuario puede ver datos de otro cambiando un identificador en la URL o en la consulta.
Los permisos se resuelven solo ocultando botones en la interfaz.

Innovación en emprendimientos

¿Lo pensamos para tu proyecto?

Pedir presupuesto WhatsApp

Cómo trabajamos

Auditoría. Revisamos tablas, vistas, funciones, buckets de Storage y el uso de las claves en todo el código.
Matriz de acceso. Definimos con vos quién puede leer, crear, modificar y borrar en cada tabla.
Políticas por operación. Escribimos políticas separadas para lectura, alta, modificación y baja. Usamos condiciones de visibilidad para lo que cada usuario puede ver y condiciones de validación para lo que puede escribir, de modo que nadie guarde una fila a nombre de otro.
Roles y organizaciones. Si tu app tiene administradores o equipos que comparten datos, las políticas consultan el rol del usuario o su pertenencia a cada organización.
Vistas y funciones. Configuramos las vistas para que respeten los permisos de quien consulta y ubicamos las funciones privilegiadas fuera del alcance de la API pública.
Rendimiento. Indexamos las columnas que usan las políticas, para que la seguridad no vuelva lenta la aplicación. Si ya hay lentitud, la atacamos con nuestra optimización de rendimiento en Supabase.
Pruebas automatizadas de cada política con distintos tipos de usuario.

Ejemplos de políticas típicas

Necesidad	Cómo se resuelve
Cada usuario ve solo sus pedidos	La política compara el dueño de la fila con el usuario de la sesión
El equipo de una empresa comparte datos	La política verifica que el usuario pertenezca a la organización de la fila
Los administradores ven todo	La política consulta el rol guardado en el perfil o en el token
Archivos privados por persona	La política de Storage limita cada carpeta a su dueño

Qué recibís

Un informe de los riesgos encontrados y cómo se corrigieron.
RLS activado y con políticas en todas las tablas expuestas.
La matriz de acceso documentada.
Pruebas automatizadas de las políticas en tu repositorio.

Las políticas dependen de saber quién es cada usuario, por eso este trabajo suele ir de la mano con la autenticación de usuarios con Supabase.

Preguntas frecuentes

¿Tenés otra duda? Escribinos por WhatsApp.

¿Es seguro que la clave pública de Supabase esté en el frontend?

Sí, está pensada para eso. La clave pública, llamada anon o publishable según la versión del panel, solo permite lo que las políticas RLS autorizan. El riesgo aparece cuando hay tablas expuestas sin RLS o con políticas demasiado amplias. La que nunca debe llegar al navegador es la clave de servicio, porque saltea todas las políticas.

¿Puedo tener datos públicos y privados en la misma tabla?

Sí. Una política puede permitir que cualquiera lea las filas marcadas como públicas, como los productos publicados, y que solo el dueño o un administrador vea las que siguen en borrador. Si hay columnas sensibles dentro de filas públicas, conviene moverlas a otra tabla o exponer una vista que muestre solo los campos permitidos.

¿Cómo sé que las políticas realmente funcionan?

Las probamos. Escribimos pruebas automatizadas que se conectan a la base como distintos usuarios, por ejemplo un cliente, otro cliente y un administrador, y verifican qué puede leer, crear, modificar y borrar cada uno. Esas pruebas quedan en tu repositorio y se pueden volver a correr cada vez que cambia el esquema.

¿RLS también protege los archivos de Storage?

Sí. Storage guarda la información de cada archivo en una tabla de la base, así que se protege con políticas igual que tus datos. Un patrón habitual es organizar los archivos en carpetas con el identificador de cada usuario y permitir que cada persona lea y suba solo dentro de la suya, y que los administradores accedan a todas.

¿Qué pasa con las funciones que usan la clave de servicio?

La clave de servicio saltea RLS, así que cualquier Edge Function o backend que la use tiene que validar por su cuenta quién hace el pedido y qué puede hacer. Revisamos esas funciones, limitamos el uso de esa clave a los casos que la necesitan y, cuando se puede, hacemos las consultas con el token del usuario.