Datos expuestos en Lovable: cómo verificar la corrección

Volver

Kevin Riedl

19 min de lectura · 4 nov 2026
Última revisión 4 de noviembre de 2026

Siguiente

Has cambiado una política de la base de datos tras recibir una alerta de seguridad. Tu cuenta sigue funcionando. Antes de dar el problema por resuelto, comprueba si otro cliente puede leer tus registros privados y si una petición sin sesión obtiene datos que no debería recibir.

Para verificar una corrección de acceso a datos en Lovable, define los permisos previstos, prueba operaciones permitidas y prohibidas con registros ficticios y repite las comprobaciones sobre las rutas de datos desplegadas, con identidades reales de la aplicación. Conserva las evidencias del antes y el después. Una prueba local de políticas valida una regla concreta; el acceso en producción necesita su propia comprobación.

Investigación actualizada al 4 de noviembre de 2026. Atribuimos las cifras del incidente a sus investigadores. Nuestro ejemplo independiente utiliza datos ficticios y políticas locales de PostgreSQL. Las comprobaciones de la aplicación alojada son un procedimiento propuesto para un entorno propio o que tengas autorización para evaluar.

Independencia y marcas: Wavect publica esta página y es también un proveedor, así que tenemos un interés comercial en ella. No estamos afiliados a las demás empresas nombradas aquí, no contamos con su respaldo y no somos socios suyos, y todos los nombres de empresa, marcas y marcas registradas de terceros pertenecen a sus respectivos titulares. Las afirmaciones sobre otros proveedores proceden de fuentes públicamente accesibles, sobre todo de sus propias páginas publicadas, en la fecha de revisión indicada en esta página, y pueden haber cambiado desde entonces. Verifícalas directamente antes de decidir. Esta página se ha redactado según nuestro leal saber y entender, con la intención de mantenernos objetivos. Si crees que algo aquí es inexacto o injusto, escríbenos y lo corregimos: [email protected]

¿Qué demuestra el informe sobre datos expuestos en Lovable?

El informe de noviembre de Crissy Field documenta lecturas sin autenticación en aplicaciones creadas con Lovable. Identificó proyectos en registros de Common Crawl fechados de diciembre de 2025 a septiembre de 2026. Sus cifras actualizan las de Handelsblatt del 2 de noviembre y describen subconjuntos distintos.

El 30 % es 7.403 de 24.664; no es una tasa confirmada de filtraciones. Puede tratarse de contactos públicos o datos de prueba. La muestra no es representativa; excluyó la base de datos propia de Lovable.

Los ejemplos incluyen más de 200.000 mensajes de un foro alemán sobre estilo de vida, más de 1.000 registros de identidad con números de pasaporte de un proveedor de servicios e información de pagos en registros de ventas. El informe no especifica campos de tarjetas de pago ni demuestra un uso indebido. Estos hallazgos no verifican la exposición ni la corrección de tu aplicación.

¿Es el mismo incidente que el del historial de chat de Lovable?

El incidente de abril sobre el historial de chat afectaba al acceso al proyecto dentro del editor de Lovable, mientras que este informe estudia la base de datos de la aplicación desplegada. En su comunicado del 22 de abril, Lovable describe una regresión que duró del 3 de febrero al 20 de abril: los usuarios autenticados de Lovable que tenían el enlace a un proyecto público podían acceder a su código fuente y al historial de chat.

Lovable afirma que corrigió esa regresión y que no afectó a los proyectos privados ni a Lovable Cloud. El comunicado no verifica los permisos de tu aplicación desplegada.

Nuestra guía de revisión técnica de aplicaciones Lovable trata la evaluación general de propiedad y preparación. Esta comprobación posterior a la corrección responde a una decisión más concreta: si puedes dar por resuelto un hallazgo de acceso a datos bien delimitado.

¿Por qué una pantalla de inicio de sesión puede dejar los datos accesibles?

La pantalla de inicio de sesión controla la interfaz. El backend debe aplicar las reglas que determinan a qué datos puede acceder cada petición. En una aplicación conectada a Supabase desde el navegador, ocultar una página o filtrar una lista con JavaScript no demuestra que la base de datos aplique la autorización. Prueba la petición de datos directamente, también sin una sesión iniciada.

La guía de claves de API de Supabase distingue una clave publicable de la identidad del usuario. Una clave publicable está pensada para clientes públicos. Sin sesión de usuario, las peticiones usan anon; con sesión iniciada, usan authenticated. Las claves secretas y las credenciales antiguas service_role requieren otro tratamiento porque sus privilegios elevados permiten omitir RLS.

La seguridad a nivel de fila, o RLS, es el mecanismo de PostgreSQL que decide a qué filas puede acceder una operación. La guía de RLS de Supabase distingue los privilegios sobre la tabla de las políticas sobre sus filas: los primeros permiten una operación en la tabla; las segundas limitan las filas a las que se aplica. Revisa ambos. Quitar un botón de la interfaz no cambia ninguno de esos permisos.

Por ejemplo, una consulta que filtra por el ID del usuario actual puede mostrar las filas correctas, aunque otra consulta más amplia permita leer más datos. Recomendamos cambiar el registro solicitado y mantener la misma identidad. El backend debe exigir que se cumpla la regla de propiedad aunque la interfaz nunca ofrezca esa petición.

¿Qué debe demostrar una prueba de permisos?

Una prueba de permisos debe demostrar que las operaciones autorizadas funcionan y los accesos prohibidos fallan con una identidad conocida. Empieza con dos usuarios ficticios y registros privados distintos. Define primero qué campos y operaciones admite cada uno. Una prueba puede validar fielmente una política que no coincide con el comportamiento previsto del producto.

Añade el contenido deliberadamente público como un caso positivo aparte. Un catálogo público debe seguir siendo accesible si esa es su función. Para los datos privados, demuestra que el propietario puede leer el registro de prueba justo antes de comprobar que otro usuario no puede. De lo contrario, una tabla vacía o un entorno que no funciona pueden hacer que todas las pruebas de denegación parezcan correctas.

Identifica también las cuentas de invitado. Los inicios de sesión anónimos de Supabase crean usuarios de Auth con el rol authenticated y el atributo is_anonymous en el JWT. Si solo debes admitir cuentas permanentes, ese rol no basta para expresar la condición. Añádela a la política y prueba la identidad correspondiente.

Para equipos y organizaciones, sustituye la regla simple de propietario por las reglas reales de pertenencia y roles. Incluye un usuario al que se haya retirado el acceso a la organización. Decide qué tareas en segundo plano siguen autorizadas tras esa retirada y comprueba esa decisión. No presupongas que todos los accesos deben desaparecer de la misma forma.

¿Qué observamos en nuestra prueba de PostgreSQL con datos ficticios?

La prueba reprodujo lecturas expuestas, dos correcciones incompletas y una política limitada por propietario y tenant. Las 23 comprobaciones registradas dieron el resultado esperado. Esto incluye confirmar el comportamiento de los estados deliberadamente inseguros. El estado corregido mantuvo las operaciones permitidas y rechazó los accesos probados entre usuarios y entre tenants distintos.

Ejecutamos Node.js 24.22.1 y @electric-sql/pglite 0.5.15, que identificó su motor como PostgreSQL 18.6. PGlite permite ejecutar PostgreSQL en memoria. El ejemplo carga tres notas: Alice y Bob comparten el tenant A; Carol pertenece al tenant B. Cada usuario es propietario de una nota.

Antes de cada operación, el programa comprueba el rol efectivo de PostgreSQL, el ID de usuario y el ID de tenant. Bob y Carol leen exactamente su propia nota de prueba. La identidad de Alice, combinada con el tenant incorrecto, obtiene cero filas. Estos controles positivos distinguen una restricción que funciona de una base de datos vacía o inaccesible.

Este fragmento reproduce exactamente la política del ejemplo. Las funciones fixture.uid() y fixture.tenant_id() leen parámetros SQL controlados por la prueba. Sustituyen localmente el contexto de identidad; no son funciones de Supabase Auth ni verifican JWT. El fragmento no es una migración para producción. Tampoco se ha probado que la pertenencia al tenant proceda de una fuente de confianza.

DROP POLICY signed_in_read ON public.notes;
CREATE POLICY private_notes ON public.notes FOR ALL TO authenticated
  USING (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id())
  WITH CHECK (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id());

La actualización, inserción y eliminación permitidas de Alice devolvieron un registro esperado cada una. Actualizar la nota de Bob o Carol, o eliminar la de Bob, devolvió cero filas. Los intentos de cambiar el propietario, cambiar de tenant o insertar una nota para Bob produjeron SQLSTATE 42501. Tras cada escritura denegada, el programa comparó una instantánea de la tabla completa y confirmó que no había cambiado.

Un rol independiente con BYPASSRLS leyó los tres registros aunque llevaba la identidad de prueba de Alice. También desactivamos RLS de nuevo de forma deliberada: la comprobación de propiedad detectó las filas adicionales. Al restaurar RLS, el resultado volvió a ser una sola fila. La prueba de regresión responde, por tanto, a un cambio real de política.

Descarga el ejemplo de regresión de políticas y los resultados registrados. Extrae el paquete y ejecuta:

npm ci --ignore-scripts
npm test

El paquete incluye el archivo de bloqueo de dependencias y results.json. Prueba privilegios y políticas de PostgreSQL con identidades locales controladas. No prueba Supabase Auth, la verificación de JWT, PostgREST, respuestas HTTP del servicio alojado, vistas, almacenamiento ni Edge Functions. Las comprobaciones sobre el despliegue que siguen siendo necesarias dependen del alcance real de tu aplicación.

¿Por qué puede fallar una corrección aunque RLS esté activado?

Una tabla con RLS activado puede seguir concediendo accesos contrarios a la regla prevista. Revisa todas las políticas y los privilegios aplicables. Después, prueba las rutas alternativas a los datos y los campos devueltos. Mantén las operaciones permitidas y limita los nuevos valores que puede guardar una escritura.

La referencia de políticas de filas de PostgreSQL explica que las políticas permisivas se combinan con OR. Añadir una política más acotada por propietario mientras conservas otra aplicable que permite todo no reduce el acceso. La misma referencia explica por qué los superusuarios, los roles con BYPASSRLS y, normalmente, los propietarios de tablas no sirven para representar a usuarios corrientes.

Las filas y los campos necesitan decisiones independientes. La guía de privilegios de columnas de Supabase indica que RLS no controla qué columnas son accesibles dentro de una fila permitida. Nosotros separaríamos los campos de perfil público de los registros internos, o definiríamos permisos de columna específicos. Comprueba si quedan privilegios sobre toda la tabla que permitan acceder a las columnas que querías restringir.

Los privilegios también pueden cambiar al llamar a una función. Supabase documenta que una función de base de datos security definer se ejecuta con los privilegios de su propietario. Restringir quién puede ejecutarla no limita automáticamente los registros de usuario que devuelve. Revisa el cuerpo de la función y prueba el resultado que recibe quien la llama.

No amplíes una política solo para que vuelva a funcionar una pantalla. Averigua primero si falta un privilegio, falla una condición de propiedad, se está usando otra identidad o el despliegue es incorrecto. Corregir la causa permite recuperar el flujo autorizado sin reabrir el acceso que originó el problema.

¿Cómo vuelves a probar la aplicación desplegada?

Repite las pruebas en cada ruta de acceso a datos incluida en el hallazgo, con identidades reales de la aplicación y registros ficticios. Registra la respuesta y cualquier cambio persistente. Así también compruebas la gestión de sesiones, la configuración y el código que atiende a los usuarios en ese momento.

La guía general de pruebas de Supabase distingue las pruebas de base de datos de las pruebas de aplicación realizadas con el cliente que esta utiliza. Lleva los mismos casos permitidos y denegados a ambos niveles. Una migración en Git documenta la intención; comprueba que el entorno de destino la haya aplicado.

1. Identifica el destino. Registra el proyecto, la revisión desplegada, la migración y las rutas autorizadas para la prueba. Usa perfiles de navegador o clientes separados para A, B y las peticiones sin sesión. Así evitas que una sesión conservada cambie la identidad sin que lo adviertas.
2. Crea registros controlados. Asigna a A y B valores ficticios claramente distintos. Conserva una lectura permitida que demuestre que el registro existe y la ruta funciona. Evita recopilar datos de clientes ajenos a la prueba como evidencia.
3. Prueba lecturas y escrituras. Incluye listas, peticiones directas de registros y las acciones reales de creación, actualización y eliminación previstas en el alcance. Revisa los campos devueltos. Tras una escritura rechazada, confirma que la fila original sigue intacta.
4. Conserva el resultado. Guarda peticiones y respuestas sin datos sensibles, la identidad efectiva, el número de filas y el estado anterior y posterior. Registra por separado la ausencia o caducidad de sesión y el caso de un usuario válido que intenta acceder a datos ajenos.

Incluye las rutas que expone tu aplicación y deja pendientes las que no hayas probado. Nuestra guía de auditoría de software creado con vibe coding explica cómo convertir ese límite en un alcance de evaluación y un entregable acordados.

¿Qué cubre el análisis de seguridad de Lovable?

Los análisis Quick y Deep de Lovable revisan el código y la configuración con coberturas distintas. Usa sus hallazgos junto con tu matriz de permisos. Un análisis no puede definir todas las reglas de negocio ni demostrar que hayas ejecutado la prueba A/B en el despliegue.

La documentación actual de seguridad indica que Quick revisa los ajustes de acceso a la base de datos, las vulnerabilidades conocidas de dependencias y la exposición de MCP sin autenticación durante la publicación. Deep añade el análisis del código de la aplicación e incluye Quick. Los análisis integrados examinan código y configuración; las pruebas de penetración opcionales sobre la aplicación en ejecución son independientes. Deep puede ejecutarse a petición, según una programación de Enterprise o al publicar una aplicación con acceso MCP sin autenticación.

La vista Security del proyecto vincula los hallazgos a una versión del código. Actualiza los análisis obsoletos y revisa los hallazgos ignorados, que no se incluyen en el recuento de pendientes. El mensaje «No issues found» indica que el último análisis no encontró problemas; la documentación afirma expresamente que los analizadores no detectan todos los riesgos. El bloqueo de publicación por hallazgos críticos depende de los controles del espacio de trabajo.

Guarda la fecha y hora del análisis y los hallazgos revisados junto con las evidencias de la nueva prueba. Inspecciona los cambios automáticos de políticas y vuelve a ejecutar la regresión. Aplica los mismos criterios de aceptación a los cambios escritos por personas y por asistentes.

¿Qué haces si ya se podían leer datos confidenciales?

Si tu aplicación devuelve datos confidenciales a alguien sin autorización, limita esa vía de acceso e involucra a los responsables de seguridad y protección de datos. Recomendamos separar la contención inmediata de la investigación: restringir el acceso puede detener nuevas lecturas, pero determinar qué accesos ocurrieron antes exige evidencias que una prueba posterior satisfactoria no aporta.

Conserva la configuración relevante, la cronología de despliegues y los registros disponibles antes de hacer cambios que destruyan información útil. Documenta qué registros y operaciones abarcaba el hallazgo. Guarda las evidencias sensibles en un lugar controlado; el gestor de incidencias debería contener normalmente reproducciones con datos ficticios o material anonimizado.

Acuerda la contención con el responsable del sistema: restringir una función expuesta, retirar un privilegio no previsto, suspender la función afectada del producto o corregir su política. Si se expuso una credencial con privilegios elevados, revócala siguiendo el procedimiento de rotación del proveedor, además de eliminar la exposición. Trata una clave publicable según su función prevista.

Una respuesta vacía después de la corrección no demuestra que los datos estuvieran protegidos antes. Las evidencias deben distinguir cuándo se observó el problema, cuándo se hizo efectiva la contención y cuándo pasó la prueba sobre el despliegue. El equipo responsable del incidente podrá evaluar las obligaciones de notificación y otras medidas a partir de los hechos.

¿Cuándo puedes dar por corregido el problema de permisos?

Da por resuelto un hallazgo de permisos cuando sus casos permitidos y denegados pasan en el alcance desplegado, los flujos autorizados siguen funcionando y las evidencias identifican el cambio y las identidades probadas. Nosotros lo dejaríamos abierto si solo hay una captura de RLS activado, una consulta de administrador satisfactoria o un análisis sin alertas, sin una nueva prueba de la aplicación.

El caso de evaluación de Cedars describe nuestro trabajo de documentación, QA y evaluación técnica con alcance delimitado. Acuerda las evidencias necesarias antes de empezar. Nuestro servicio de pruebas de penetración permite definir una evaluación autorizada y una comprobación posterior de la aplicación en ejecución.

Usa la lista de control de QA antes del lanzamiento para decidir sobre el lanzamiento completo. Para este hallazgo, exige que la petición permitida funcione y la prohibida falle sobre la misma revisión desplegada. Conserva ambos resultados antes de cerrarlo.