Una app hecha en Lovable puede pasar de idea a enlace público en una tarde. El riesgo aparece cuando «funciona» se confunde con «cada usuario solo puede ver sus datos». Un panel de clientes que muestra la fila de otra persona convierte una demo en un incidente. El 10 de noviembre de 2026, Lovable explicó qué seguridad revisa automáticamente, qué hallazgos puede corregir y cuál sigue siendo la decisión del creador. Úsalo como punto de partida para una prueba de tres identidades antes de publicar.

Lo que hace Lovable y lo que debes revisar

Según Lovable, el flujo de publicación ejecuta escáneres que revisan código, lógica, esquema de base de datos y políticas RLS, las reglas que controlan qué filas ve y modifica cada usuario. También permite un análisis profundo bajo demanda y ofrece una acción Fix para hallazgos concretos. La opción de corrección automática se configura en el proyecto; algunas organizaciones pueden bloquear publicaciones con hallazgos críticos. El anuncio del 10 de noviembre no significa que un escáner haya aprobado tu app ni que la protección sea infalible.

Una distinción útil de la documentación anterior de Lovable: el escaneo básico antes de publicar cubre errores comunes de configuración y acceso; el análisis profundo revisa código y lógica con más detalle. Programar análisis periódicos en todos los planes de pago aparece en el artículo reciente como algo que llegará durante el mes, no como capacidad ya disponible para cada cuenta. Verifica tu plan y el estado del control antes de prometerlo a clientes.

Prueba manual con dos usuarios y una sesión vacía

Crea dos cuentas de prueba, A y B, sin datos personales reales. Inserta un registro reconocible para cada una, por ejemplo A-001 y B-001, en la función principal de tu app. Si tu producto maneja archivos, usa archivos de prueba inocuos. Define la regla antes de ejecutar: A debe ver y editar solo A-001; B solo B-001; una sesión anónima no debe ver ninguno.

1. Entra como A en una ventana normal. Abre su registro, copia la URL o el identificador visible y comprueba que editarlo funciona.
2. En otra ventana privada entra como B. Intenta abrir la URL de A. Comprueba que el servidor o la base de datos deniega lectura y escritura; ocultar un botón en la interfaz no basta.
3. Cierra sesión e intenta la misma URL sin autenticación. Comprueba que no aparece ni la ficha ni un archivo privado descargable.
4. Repite el cruce inverso: A intenta leer B-001. Anota fecha, entorno, cuentas ficticias, resultado esperado y resultado observado. Conserva capturas de tus pruebas, sin secretos ni datos reales.

Si B obtiene datos de A, detén la publicación. Revisa la política RLS de la tabla, el identificador de propietario que se guarda al crear filas y las funciones de servidor que saltan o elevan permisos. El propio checklist de Lovable recalca que habilitar RLS no demuestra que cada política sea correcta. Vuelve a probar después de Fix o cualquier cambio del agente: una reparación puede cerrar el acceso indebido y a la vez romper el flujo legítimo.

Completa la revisión antes de pulsar Publish

Ejecuta el análisis profundo si vas a abrir la app al público, manejar datos sensibles o acabas de cambiar la arquitectura. Atiende los hallazgos críticos y revisa los avisos en lugar de descartarlos por rutina. Comprueba además que las claves de terceros están en almacenamiento de secretos del servidor y que no aparecen en archivos JavaScript enviados al navegador. Lovable afirma que su plataforma protege secretos y ofrece controles, pero el creador sigue siendo responsable de su app, sus políticas de acceso y las integraciones que conectó.

Un prompt útil para el agente de Lovable, que complementa la prueba manual, es: «Revisa las tablas con datos de usuarios y sus políticas RLS. Para cada tabla indica qué puede leer, crear, actualizar y borrar un usuario A, un usuario B y una sesión anónima. Señala rutas o funciones que usen privilegios elevados. No cambies nada todavía; devuelve los archivos o políticas exactas que justifican cada conclusión». Copia el resultado, verifica cada referencia en el proyecto y aplica cambios solo después de entender su efecto.

Regla de salida: publica cuando el escaneo no tenga hallazgos críticos sin resolver, las tres sesiones den los resultados esperados y los secretos no salgan al cliente. Ninguna de esas comprobaciones sustituye una evaluación profesional para sistemas de alto riesgo. Este artículo describe un protocolo reproducible basado en documentación oficial; no hemos ejecutado la prueba en una app de Lovable de Joseph.