¿Es segura mi app hecha con Lovable? Cómo revisarlo tú mismo

¿Es segura mi app hecha con Lovable? Depende de cómo quedó configurada, no de Lovable en sí. La plataforma es confiable y trae herramientas de seguridad, pero la IA puede dejar tu base de datos abierta a cualquiera si las reglas de acceso (RLS) faltan o están mal, o meter una llave secreta donde no debe. Abajo están las revisiones concretas que puedes hacer hoy, en orden de importancia.

Por qué la pregunta importa

En mayo de 2025 se publicó la vulnerabilidad CVE-2025-48757: de 1,645 apps de la vitrina de Lovable, 170 dejaban leer o escribir tablas de Supabase con la llave pública anon, la que va en el navegador y cualquiera puede ver. No era una falla “de Lovable” en el sentido de que alguien hackeara la plataforma; era que esas apps no tenían bien sus reglas de acceso.

Lo importante: así se ve una app hecha con IA que funciona perfecto y aun así está abierta. Que tu app “jale” no dice nada de si es segura.

Lovable es seguro, pero ¿y tu app? Las 7 revisiones

1. Corre el escaneo de seguridad de Lovable

Según la documentación de seguridad de Lovable (noviembre de 2026):

• Quick scan: se ejecuta solo al publicar; revisa la base de datos, dependencias y más. Lo ves en la vista Security del proyecto y en el diálogo de publicar.
• Deep scan: revisa todo el código (control de accesos, inyecciones). No corre solo: lánzalo desde la vista Security o el Security center.

Haz el Deep scan y lee cada hallazgo. No los ignores porque “la app funciona”.

2. Revisa que todas tus tablas tengan RLS

RLS (Row Level Security) son las reglas que dicen qué filas de cada tabla puede ver o cambiar cada usuario. Sin RLS, cualquiera con la dirección de tu proyecto puede leer y borrar todo.

• En Lovable: More → Database → Manage → Policies.
• En Supabase (si lo conectaste directo): Advisors → Security Advisor. Si ves el aviso “Table publicly accessible” o rls_disabled_in_public, es urgente. Lo explicamos en Supabase RLS disabled in public.

Si no sabes qué es RLS, empieza por RLS en Supabase: qué es.

3. Revisa que RLS no esté “abierto de mentiras”

Muy común en apps hechas con IA: RLS está activado, pero la política dice using (true), que significa “todos pueden todo”. Es como poner cerradura y dejar la llave pegada. Revisa cada política y pregúntate: ¿esto deja que un usuario vea datos de otro? Ejemplos correctos en políticas RLS de Supabase: ejemplos.

4. Prueba con dos cuentas

La prueba más útil y que puedes hacer sin saber programar:

1. Crea dos usuarios de prueba (A y B).
2. Con A, crea datos (un pedido, un perfil, un documento).
3. Entra con B. ¿Puedes ver, editar o borrar lo de A? Prueba también cambiando el número o ID en la dirección del navegador (/pedido/15 → /pedido/16).
4. Si B ve algo de A que no debería, tienes un problema de acceso.

Solo haz esto con tu propia app y tus cuentas de prueba.

5. Busca llaves secretas en el frontend

La llave pública de Supabase (anon o publishable) está bien que vaya en el navegador. La service_role o secret (sb_secret_...) nunca: se salta todas las reglas RLS. Tampoco deben ir en el frontend llaves de OpenAI, Stripe (la secreta), Mercado Pago (access token) o similares.

Cómo revisar: abre tu app publicada, F12 → Sources y busca (Ctrl+Shift+F) textos como service_role, sb_secret_, sk_live, sk-. Si encuentras algo, lee Supabase service_role key expuesta.

6. Revisa quién es “administrador” y cómo se decide

Si tu app tiene un panel de admin, ¿cómo sabe quién es admin? Si es por un campo que el mismo usuario puede editar en su perfil (is_admin = true), cualquiera se puede volver admin. Los roles deben guardarse en una tabla que el usuario no pueda modificar, y revisarse en la base de datos, no solo ocultando botones en la pantalla.

7. Revisa el almacenamiento de archivos

Si tus usuarios suben fotos, INE, comprobantes o contratos, revisa los buckets de Supabase Storage. Un bucket público deja que cualquiera con el enlace vea el archivo. Para documentos personales, usa buckets privados con políticas.

Seguridad de apps hechas con IA: por qué pasa esto

La IA optimiza para que la app funcione cuando la pruebas. Si una regla de seguridad bloquea algo, la “solución” más rápida que encuentra a veces es abrir el acceso. Además, tú pruebas con tu cuenta y todo se ve bien; el problema solo aparece cuando otra persona intenta ver lo que no le toca.

Señales de alarma

• Le pediste a la IA “arregla el error de permisos” y desde entonces todo funciona… demasiado bien.
• Ves using (true) en tus políticas.
• Tienes tablas con datos personales (correos, teléfonos, direcciones) sin RLS.
• Alguna vez pegaste la llave service_role en el chat de Lovable.
• Tu app maneja dinero, salud, documentos oficiales o datos de menores.

Cuándo no es para hacerlo tú

Si tu app ya tiene usuarios reales, guarda datos personales o cobra, la revisión debería hacerla alguien que sepa leer políticas SQL y probar accesos. Un error en una política puede exponer a todos tus clientes, y en México eso también tiene implicaciones legales de protección de datos. Usa nuestra checklist de seguridad para apps hechas con IA como guía mínima.

En resumen

Lovable es una plataforma seria, pero tu app es segura solo si sus tablas tienen RLS bien hecho, no hay llaves secretas en el navegador y los permisos se validan en la base de datos. Corre el escaneo, prueba con dos cuentas y revisa las políticas. Si encuentras algo raro o prefieres que lo revise alguien con experiencia antes de que lo encuentre otra persona, en Black Engine lo revisamos contigo por WhatsApp.