Supabase sin Row Level Security: por qué las apps hechas con IA filtran datos

Por Kike Gandia · Co-Fundador y CEO, OSCP

Si construiste tu aplicación con Lovable, Bolt, v0 o Replit, lo más probable es que sus datos vivan en Supabase o en un servicio equivalente, y que el navegador hable directamente con esa base de datos. Es una arquitectura moderna y perfectamente válida, pero descansa por completo en una pieza que hay que configurar a mano: Row Level Security. Sin ella, la aplicación sigue funcionando igual de bien y la base de datos queda legible para cualquiera. Esta guía explica por qué ocurre, cómo comprobarlo en tu aplicación y qué hay que dejar cerrado.

Qué es Row Level Security y por qué aquí lo es todo

En una arquitectura clásica, el navegador habla con tu servidor y tu servidor habla con la base de datos. El servidor es el que decide qué puede ver cada usuario, y la base de datos nunca queda expuesta.

En la arquitectura que usan los generadores no hay servidor intermedio: el navegador consulta la base de datos directamente, usando una clave pública que viaja en el propio front. Eso significa que la decisión de "qué puede ver este usuario" ya no la toma tu código: la toma la base de datos, fila por fila. Row Level Security es el mecanismo que lo hace.

De ahí que sea la pieza crítica. No es una capa de refuerzo opcional: es el único control de acceso que existe en ese diseño. Si está desactivada, la clave pública que cualquiera puede leer en el navegador sirve para pedir el contenido completo de las tablas.

Por qué queda sin activar tan a menudo

No es descuido ni mala fe de las herramientas, es una consecuencia de cómo se construye con ellas.

Mientras desarrollas, RLS estorba: activa reglas que bloquean consultas y el generador no siempre sabe escribirlas correctamente a la primera. Lo cómodo es dejarla desactivada para que todo funcione, seguir construyendo y "activarla antes de publicar". Ese último paso rara vez ocurre, porque nada recuerda que falta: la aplicación está terminada, funciona, y no hay ningún síntoma.

A eso se suma un malentendido frecuente sobre la clave. La clave que el front usa se llama pública o anónima, y quien construye asume razonablemente que si es pública no da acceso a nada sensible. Pero lo que limita su alcance no es la clave: son las políticas RLS. Sin políticas, la clave pública lee todo.

Cómo comprobar si tu aplicación está expuesta

Tres comprobaciones, de menos a más concluyente. Hazlas sobre tu propia aplicación, nunca sobre la de un tercero.

1. Localiza la conexión. Abre tu aplicación, entra en las herramientas de desarrollo del navegador y mira la pestaña de red. Verás peticiones a la dirección de tu proyecto de base de datos y la clave con la que se conecta. Que sean visibles es normal y esperado; el problema nunca es que se vean.

2. Consulta sin sesión. Cierra sesión por completo, o abre una ventana privada, y repite una consulta de datos. Si sigues recibiendo registros, no hay control de acceso: cualquiera puede hacer lo mismo.

3. Consulta desde otra cuenta. Crea una segunda cuenta y comprueba si desde ella puedes recuperar registros creados por la primera. Si puedes, RLS está activada pero las políticas no comprueban propiedad, que es el error más común después de no activarla en absoluto.

Si la primera comprobación ya devuelve datos sin sesión, no hace falta seguir: tienes la base de datos abierta y conviene cerrarla hoy.

Qué hay que dejar cerrado, no solo activado

Activar RLS es el primer paso y no es suficiente. Lo que hay que verificar, tabla por tabla:

RLS activada en todas las tablas, incluidas las auxiliares. Una tabla olvidada suele contener precisamente lo que relaciona usuarios con datos.
Políticas que comprueban propiedad, no solo autenticación. La diferencia entre "hay sesión" y "este registro es de quien pregunta" es la diferencia entre estar protegido y no estarlo.
Políticas separadas para lectura y escritura. Es habitual cerrar la lectura y dejar la escritura abierta, lo que permite modificar o borrar datos ajenos.
Reglas equivalentes en el almacenamiento de ficheros. Los buckets tienen su propio sistema de permisos y no heredan las políticas de las tablas.
La clave de servicio nunca en el front. Existe una segunda clave con privilegios totales que ignora RLS por diseño. Si acaba en el navegador, todo lo anterior deja de importar.

Qué pasa cuando ya se ha filtrado

Si las comprobaciones anteriores confirman que la base de datos ha estado accesible, cerrar las políticas es necesario pero no cierra el asunto. Los datos han podido ser leídos, y no vas a poder demostrar que no lo fueron: los accesos por la vía pública no dejan el mismo rastro que una intrusión.

Si hay datos personales de residentes en la UE, hay que evaluar si procede notificar a la autoridad de control en 72 horas. La evaluación es del responsable del tratamiento, y conviene documentarla aunque la conclusión sea que no procede notificar: esa documentación es lo que se pide después.

En paralelo, rota las claves, revisa los registros de acceso que conserve el proveedor y comprueba si hubo escrituras anómalas. Es la parte que más se olvida: casi todo el mundo piensa en quién pudo leer y casi nadie en quién pudo escribir.

FAQ

¿Esto es un fallo de Supabase o de Lovable?

De ninguno de los dos. Supabase documenta RLS de forma prominente y avisa cuando una tabla está sin proteger; los generadores construyen sobre ese modelo y también lo advierten. El control de acceso es, por diseño, responsabilidad de quien publica la aplicación. Lo que sí es cierto es que el diseño concentra todo el riesgo en un único paso de configuración, y que ese paso es fácil de posponer indefinidamente.

Uso Firebase en lugar de Supabase, ¿me aplica igual?

Sí, con otro nombre. Firebase tiene Security Rules y el mismo modelo de fondo: el cliente habla directamente con los datos y las reglas son el único control de acceso. Las reglas en modo de prueba abren la base de datos durante un periodo y muchas aplicaciones nunca salen de ese modo. Las comprobaciones de esta guía son equivalentes.

¿Puedo activar RLS con la aplicación ya en producción?

Sí, y es lo recomendable, pero hazlo con cuidado porque activarla sin políticas bloquea todas las consultas y la aplicación deja de funcionar. El orden seguro es escribir primero las políticas, probarlas en un entorno de copia, y activar después tabla por tabla verificando la aplicación entre paso y paso. Una hora de trabajo ordenado frente a una caída en caliente.