Tu MVP en Lovable funciona. Mira lo que se va a filtrar

Lovable logra algo que hace poco parecía imposible: describes un producto y en una tarde tienes pantallas, login y base de datos funcionando. Me parece genial para validar una idea. El problema empieza cuando confundimos “funciona” con “puede salir en línea con datos de personas reales”.

El 27 de febrero de 2026, The Register publicó, en un reportaje de Connor Jones, el caso de una app alojada en Lovable y listada en el escaparate de la plataforma. El investigador Taimur Khan encontró 16 fallos, seis críticos. El resultado: 18.697 registros de usuarios expuestos.

Qué pasó con la app del escaparate de Lovable

La app tenía más de 100 mil visualizaciones y unos 400 votos cuando Khan empezó el análisis. La usaban profesores y alumnos, incluidas personas de UC Berkeley y UC Davis. De los registros expuestos, 14.928 eran correos únicos, 4.538 eran cuentas de estudiantes y 870 usuarios tenían sus datos personales completos a la vista.

Los fallos no eran sofisticados:

• Base de datos sin reglas de acceso por fila. El backend en Supabase no tenía row-level security ni control por rol. Quien llegaba a la base de datos lo veía todo.
• Login con la lógica invertida. Una función de autenticación bloqueaba a quien había iniciado sesión y dejaba pasar a quien no. En palabras de Khan: “The guard blocks the people it should allow and allows the people it should block.”
• Poder de administrador para cualquiera. Un visitante sin login podía ver a todos los usuarios, enviar correos masivos, borrar cuentas y cambiar notas.

Lovable respondió que se toma este tipo de hallazgos “extremely seriously” y que actuó minutos después de recibir el reporte formal. Su CISO, Igor Andriushchenko, dijo que cada proyecto pasa por un escaneo gratuito antes de publicarse, pero que aplicar las recomendaciones es decisión del usuario. La empresa también afirmó que el proyecto tenía código no generado por Lovable y que la base de datos vulnerable no estaba alojada por ella.

Por qué no es solo un problema de Lovable

El mismo reportaje cita a Veracode: el 45% del código generado por IA tenía fallas de seguridad. O sea, el riesgo no está en una herramienta concreta. Está en la forma en que la IA escribe código: entrega el camino feliz, aquel en el que el usuario hace exactamente lo que imaginaste.

La seguridad es justo el camino infeliz. Es lo que pasa cuando alguien abre la app sin login, cambia un número en la URL o llama directo a la API. La IA no lo prueba por su cuenta. Y la pantalla no muestra nada raro, porque la pantalla funciona.

Checklist de seguridad antes de lanzar tu MVP

Esta es la lista que yo pasaría a cualquier MVP hecho con Lovable, Bolt, Replit o similares antes de abrirlo a usuarios reales. No sustituye una revisión completa, pero detecta el tipo de fallo del caso anterior.

Base de datos

1. Row-level security activada en todas las tablas. En Supabase, una tabla sin RLS queda accesible para quien tenga la clave pública, que está en tu front-end.
2. Políticas escritas por rol. El alumno ve sus propios datos. El profesor ve su grupo. El admin lo ve todo. Cada regla tiene que existir en la base de datos, no solo en la pantalla.
3. Prueba con dos usuarios. Crea dos cuentas e intenta, con la segunda, leer o editar datos de la primera.

Autenticación

4. Abre la app en una ventana de incógnito. Recorre todas las rutas sin login. No debe cargar nada privado.
5. Lee la función que protege las rutas. Comprueba que la condición va en el sentido correcto. El caso anterior muestra que basta una negación invertida.
6. Acciones de admin verificadas en el servidor. Ocultar el botón no protege nada. La API tiene que rechazar la petición.

Claves y secretos

7. Ninguna clave secreta en el front-end. Las claves de servicio de la base de datos, de pagos o de correo van solo en el servidor.
8. Variables de entorno revisadas. Comprueba qué llega al navegador y qué se queda en el servidor.

Datos y operación

9. Recoge solo lo necesario. Cada campo personal de más es un campo más que se puede filtrar.
10. Límite de envíos y de peticiones. Una ruta que envía correos sin límite se convierte en una herramienta de spam.
11. Un canal de contacto para quien encuentre fallos. Khan cuenta que su primer reporte se cerró sin respuesta. Ten un correo claro y responde.
12. Ejecuta el escaneo de la plataforma y aplica lo que señala. Existe. Ignorar la recomendación es el fallo más barato de evitar.

Qué cambia esto para ti

Si tu MVP se hizo en una de estas herramientas, probablemente está más cerca del lanzamiento que un proyecto desde cero. Eso es bueno. Solo no te saltes el paso que la IA no hace sola, parte del 30% que le falta a tu MVP.

En el Studio usamos Claude Code y Figma en el diseño y el desarrollo, y cada sistema sale con un agente de IA que se ejecuta a diario, señala fallos, sugiere mejoras y comprueba que los datos tengan sentido. En el diagnóstico de un MVP heredado, revisamos login y permisos, claves expuestas, reglas de acceso a la base de datos y dependencias antes de hablar de precio.

Después del diagnóstico, recibes precio cerrado y plazo por escrito en el contrato para llevar el MVP al punto en que puede recibir usuarios reales. Si tu app en Lovable ya funciona y quieres estar seguro de que no va a filtrar datos en el primer mes, el rescate de proyectos del Studio está pensado para ese momento.