¿Es seguro Lovable? Qué revisar antes de poner datos reales en la app

La respuesta corta

Lovable tiene herramientas de seguridad buenas y gratuitas. No garantizan que su app sea segura. La propia documentación indica que usted es responsable de que la app cumpla los requisitos de seguridad de su caso de uso, y que las herramientas no reemplazan una revisión completa (Lovable, Security).

En la práctica, la pregunta útil es “¿la app que armé en Lovable es segura?”. Eso depende de cómo se configuraron las tablas, las claves y las rutas. Usted puede revisar casi todo por su cuenta, en una tarde.

Lo que Lovable ya revisa por su cuenta

Hay dos tipos de escaneo (Lovable, Security):

• Quick scan: se ejecuta solo al publicar. Revisa la base de datos (tablas sin RLS, reglas que dejan pasar a todos, protección contra contraseñas filtradas desactivada), las dependencias y los servidores MCP sin autenticación.
• Deep scan: lee todo el código. Busca control de acceso defectuoso, rutas sin login o fáciles de abusar, inyección, secretos filtrados, fallas en pagos y en el login, y datos personales expuestos. No se ejecuta solo. Debe iniciarlo en la pantalla de seguridad del proyecto o en el diálogo de publicación.

Los hallazgos vienen marcados como Critical, Warning o Info.

Por qué la app puede filtrar datos de todos modos

La app hecha en Lovable corre en el navegador y habla directo con la base de datos (Lovable Cloud está construido sobre Supabase). Para eso, una clave pública viaja junto con el sitio. Es normal y está previsto: la clave publicable de Supabase está hecha para quedar expuesta (Supabase, API keys).

Lo que protege los datos es otra cosa: las reglas de acceso por fila, el RLS. La documentación de Supabase es directa: una tabla expuesta sin RLS puede ser leída y modificada por cualquier rol con permisos sobre ella (Supabase, Row Level Security). Es decir, quien abre el sitio puede tomar la clave pública y leer la tabla completa.

Lo mismo vale para la lógica. Ocultar un botón a quien no es administrador no impide que alguien llame a la función que ese botón ejecuta. Lovable lo advierte: use el estado de login del navegador solo para controlar la pantalla, nunca para conceder acceso (Lovable, Security best practices). El control de acceso roto es el primer punto del OWASP Top 10 de 2025 (OWASP, A01:2025).

Checklist en 7 pasos

Siga el orden. Anote lo que encuentre.

1. Ejecute el Deep scan y resuelva los críticos

Abra la vista de seguridad del proyecto e inicie el Deep scan. Corrija todo lo que aparezca como Critical antes de seguir. Después, en la configuración del workspace, active la opción que bloquea la publicación cuando hay problemas críticos (Block publishing with critical issues), recomendada por Lovable (Lovable, Security).

2. Busque claves secretas en el sitio publicado

Lovable indica que un secreto guardado en el código del front-end es visible para el usuario y debe considerarse comprometido (Lovable, Security best practices). Para revisarlo:

1. Abra su sitio publicado en Chrome.
2. Presione F12, vaya a Sources y use la búsqueda en todos los archivos (Ctrl+Shift+F).
3. Busque service_role, sb_secret_, secret, sk_live, sk_test y api_key.
4. Haga la misma búsqueda en el repositorio de GitHub, si está conectado.

La clave publicable de Supabase (sb_publishable_... o la antigua anon) puede aparecer. La clave secreta (sb_secret_... o la antigua service_role) no. Ignora todas las reglas de RLS (Supabase, API keys). Tampoco pueden estar ahí claves secretas de pagos, correo o IA. Su lugar es el recurso Secrets de Lovable, leído solo por código de servidor.

3. Revise el RLS de cada tabla

En Lovable Cloud, las políticas están en More → Database → Manage → Policies. La pantalla es solo de lectura: para cambiar algo, se lo pide a Lovable en el chat (Lovable, Database access).

Si la app usa un Supabase propio, abra el Security Advisor en el panel de Supabase. Aquí importan tres alertas (Supabase, Database Advisors):

• 0013_rls_disabled_in_public: tabla pública con RLS desactivado. Cualquier persona con la URL del proyecto lee, edita y borra las filas. Es la más grave.
• 0007_policy_exists_rls_disabled: la política existe, pero el RLS está desactivado, así que no tiene efecto.
• 0010_security_definer_view: una vista que pasa por encima del RLS.

Cada tabla nueva también necesita política. Lovable recomienda revisarlo cada vez que la app gana una tabla (Lovable, Security best practices).

4. Pruebe como un extraño y como otro cliente

Leer la política no basta. Pruebe:

1. Abra la app en una pestaña de incógnito, sin login, e intente abrir las páginas internas por su dirección directa.
2. Cree dos usuarios de prueba, A y B. Con A, cree un registro. Entre con B e intente ver, editar o borrar el registro de A, incluso cambiando el ID en la dirección.
3. Si B ve el dato de A, la política está mal. Deténgase y corríjala antes de abrir la app a clientes.

Lovable pide exactamente esta prueba: confirmar que un usuario no ve los datos privados de otro (Lovable, Security best practices).

5. Revise las funciones de servidor

Toda Edge Function o ruta de API debe verificar quién la llama y qué puede hacer esa persona. Esto vale también cuando alguien llama a la función directamente, fuera de la pantalla de la app (Lovable, Security best practices).

Tenga el doble de cuidado con las funciones que usan la clave secreta. Pasan por encima del RLS, así que la propia función debe revisar el permiso. Pagos, registros y cualquier flujo de varias etapas deben correr en el servidor.

6. Revise quién ve el proyecto y el login

• App interna: visibilidad del workspace y login obligatorio.
• Confirme que la app está publicada como pública a propósito.
• Active la protección contra contraseñas filtradas en el login con correo y contraseña.
• Revise quién tiene acceso al workspace.

Todos estos puntos están en la documentación de Lovable (Security y Security best practices).

7. Revise la LGPD

Si su app guarda nombre, correo, teléfono o CPF de personas en Brasil, trata datos personales bajo la LGPD (la ley brasileña de protección de datos). La LGPD obliga a quien trata datos a adoptar medidas de seguridad contra el acceso no autorizado (Lei 13.709/2018, art. 46). En la práctica, los pasos 2 a 6 forman parte de eso.

Tenga también una política de privacidad que diga qué recopila la app y para qué. Y conozca el plazo: si hay un incidente con riesgo o daño relevante para los titulares, el controlador debe comunicarlo a la ANPD y a los titulares en tres días hábiles (ANPD, Comunicação de incidente de segurança).

¿Encontró una clave filtrada? Siga este orden

Este es el orden que indica Supabase para una clave secreta (Supabase, API keys), y la lógica sirve para cualquier servicio:

1. Corrija la causa: saque la clave del código del front-end.
2. Cree una clave nueva en el panel (en Supabase, en Settings → API Keys).
3. Reemplace la clave en todos los lugares que la usan y confirme que todo funciona.
4. Solo entonces desactive la clave antigua. Borrar una clave secreta no tiene vuelta atrás.

Cambiar la clave no borra lo que ya se leyó con ella. Si la tabla estaba abierta y tenía datos personales, evalúe si hubo un incidente (paso 7).

Cuándo conviene pedir ayuda

El propio Lovable sugiere una revisión profesional para apps con datos sensibles o funciones críticas, y una prueba de penetración antes de un lanzamiento grande (Lovable, Security). Conviene considerarlo cuando:

• la app guarda datos personales de clientes, de salud o financieros;
• usted no puede decir quién puede leer cada tabla;
• el Deep scan señala algo que no sabe corregir;
• la app se va a difundir y el número de usuarios va a crecer.

Ninguna revisión elimina el riesgo. Lo reduce y muestra lo que falta.

Pida el diagnóstico de Heartscale

Heartscale se ocupa de apps hechas con IA. En el diagnóstico, nuestro equipo revisa las claves, el RLS, las rutas, las funciones de servidor, las dependencias y la protección de datos de su app. Usted recibe un informe con los hallazgos por gravedad y el precio de cada corrección.

El diagnóstico cuesta US$ 79 y se descuenta si contrata la corrección, la migración o el plan mensual. Solo trabajamos en apps de quien demuestra ser su dueño.

Pedir el diagnóstico de mi app