Respuesta corta: publicar una aplicación hecha con Lovable es seguro si has resuelto tres cosas que la herramienta no resuelve por ti —el control de acceso a tus datos, las claves que acaban en el navegador y los límites de uso y gasto—. Si no las has tocado, lo más probable es que tu aplicación sea accesible para cualquiera que sepa abrir las herramientas de desarrollo del navegador. No porque Lovable sea insegura, sino porque lo que protege una aplicación no es el generador de código: son decisiones que alguien tiene que tomar y que, mientras construyes, nadie te pide.
La misma respuesta vale para Bolt, v0, Replit, Base44 o Cursor. La plataforma cambia; el reparto de responsabilidad no.
Esta guía la firma Miguel Quílez, director de Hiberus Booster, la unidad del grupo Hiberus especializada en inteligencia artificial. Hiberus es la primera consultora tecnológica española de capital privado, con más de 4.000 profesionales.
Qué protege la plataforma y qué te toca a ti
Este es el punto donde se producen casi todos los malentendidos. Las plataformas de desarrollo con IA se apoyan en infraestructura seria —Supabase, Vercel, Cloudflare, Netlify— y eso lleva a asumir que la seguridad viene incluida. Viene incluida la mitad:
| Lo resuelve la plataforma | Lo decides tú (y si no lo decides, queda abierto) |
|---|---|
| Cifrado del tráfico (HTTPS) y certificados | Quién puede leer y escribir cada fila de tus tablas |
| Servidores parcheados y actualizados | Qué claves acaban en el código que descarga el navegador |
| El sistema de registro e inicio de sesión | Si un usuario que ha iniciado sesión puede ver datos de otro |
| Alta disponibilidad de la infraestructura | Los límites de peticiones y el tope de gasto mensual |
| Copias de seguridad automáticas del servicio | Que esas copias se hayan restaurado alguna vez |
| Cumplimiento de la propia plataforma | Tu cumplimiento del RGPD como responsable del tratamiento |
La columna de la derecha es la que define si publicar es seguro. Y es la columna que un asistente de IA no te obliga a rellenar, porque su objetivo es enseñarte algo funcionando cuanto antes.
El fallo número uno: la base de datos abierta
Lovable y herramientas equivalentes conectan tu aplicación directamente con la base de datos, normalmente Supabase. El navegador del usuario habla con la base de datos sin pasar por un servidor intermedio tuyo. Es rápido de construir y es una arquitectura legítima, siempre que las reglas de acceso por fila estén activadas y bien escritas.
Esas reglas —Row Level Security, RLS— son lo único que impide que un usuario pida la tabla entera. Y durante el desarrollo estorban: si están activadas y aún no has escrito la política correcta, no ves tus propios datos. La salida rápida es desactivarlas. La consecuencia es que cualquiera puede leer la tabla completa de clientes desde la consola del navegador, sin herramientas especiales y sin ser un atacante.
Tener RLS activado tampoco basta. Una política mal escrita —la clásica que permite leer a cualquier usuario autenticado, en vez de solo al dueño de la fila— deja la puerta igual de abierta con el candado puesto.
El fallo número dos: claves en el navegador
Hay dos tipos de clave y confundirlas es caro. La clave pública (anon key) está diseñada para vivir en el navegador y no da acceso por sí sola: depende de las reglas por fila. La clave de servicio (service role) se salta todas las reglas por diseño y solo debe existir en el servidor.
Cuando un asistente resuelve un problema de permisos usando la clave de servicio desde el lado del cliente —porque así funciona a la primera—, esa clave viaja al navegador de todos tus usuarios. Quien la copie tiene control total sobre la base de datos, incluidas las tablas que las reglas protegían.
Lo mismo aplica a las claves de OpenAI o Anthropic, a las del proveedor de correo y a las de la pasarela de pago. En el caso de una clave de IA el daño es inmediato y medible: alguien la usa y la factura llega a tu tarjeta.
El fallo número tres: sin límites de uso ni de gasto
Una aplicación pública sin límite de peticiones es un formulario que alguien puede rellenar diez mil veces en un minuto. Si detrás hay un modelo de IA, cada envío cuesta dinero. Si detrás hay un envío de correo, tu dominio acaba marcado como spam.
Antes de publicar, dos números tienen que estar configurados: el tope de gasto mensual en cada proveedor de pago por uso, y un límite de peticiones por usuario y por minuto en los puntos de entrada que cuestan dinero. Ninguno viene puesto por defecto.
Y el RGPD: publicar en España no es solo un asunto técnico
Desde el momento en que una persona introduce su nombre y su correo en tu aplicación, eres responsable del tratamiento de sus datos. Eso implica, como mínimo:
- Saber dónde se alojan los datos. Muchas plataformas crean el proyecto por defecto en Estados Unidos. Se puede elegir región europea, pero hay que elegirla —y en la mayoría de los casos hay que hacerlo al crear el proyecto, no después—.
- Tener una base legal para cada dato que pides. Si pides el teléfono «por si acaso», no la tienes.
- Una política de privacidad que describa tu aplicación real, no una plantilla generada que menciona servicios que no usas.
- Poder atender una solicitud de borrado sin entrar a mano en la base de datos a buscar filas.
- Contratos de encargado del tratamiento con los proveedores que tocan datos personales: la plataforma, el proveedor de correo, el de analítica.
No es un trámite de última hora. Es una de las capas que revisa cualquier auditoría seria, y en España es la que puede convertir un fallo técnico en una sanción.
La lista antes de dar la dirección a nadie
Ocho comprobaciones. Ninguna requiere saber programar, y todas se hacen en una tarde:
- Cada tabla con datos de personas tiene reglas por fila activadas y probadas con dos cuentas distintas.
- Ninguna clave de servicio aparece en el código del navegador (busca «service_role» en el código fuente de la página).
- Las llamadas a modelos de IA y a la pasarela de pago pasan por una función en el servidor, no directamente desde el navegador.
- Hay tope de gasto configurado en todos los proveedores de pago por uso.
- Hay límite de peticiones en los formularios públicos y en los puntos de entrada que cuestan dinero.
- Has restaurado una copia de seguridad al menos una vez, y sabes cuánto tardaste.
- Los datos están alojados en la Unión Europea, o tienes documentada la base legal para que no lo estén.
- Recibes un aviso cuando algo falla, en lugar de enterarte porque un cliente te escribe.
Entonces, ¿publico o no?
Depende de qué guarda tu aplicación y de a quién se la vas a enseñar:
| Situación | Recomendación |
|---|---|
| Prototipo interno, datos ficticios, tres usuarios de tu empresa | Publica. El riesgo real es que la idea no interese, no que el código falle. |
| Lista de espera o formulario de captación sin datos sensibles | Publica tras las comprobaciones 1 a 5 de la lista. |
| Clientes reales, datos personales, cobros | Revisión completa antes de abrir. Aquí un fallo cuesta clientes y puede costar una sanción. |
| Datos de salud, menores, datos financieros de terceros | Revisión externa obligatoria, sin excepción. Son categorías especiales bajo el RGPD. |
La pregunta útil, otra vez, no es cómo se construyó la aplicación. Es qué pasa el día que falle: si la respuesta es «nada grave», publica y aprende con usuarios reales. Si la respuesta incluye datos de clientes, dinero o tu reputación, la revisión sale mucho más barata que el incidente.
Preguntas frecuentes
¿Es seguro publicar una aplicación hecha con Lovable?
Lo es si has resuelto tres cosas que la herramienta no resuelve sola: el control de acceso por fila a tus tablas, las claves que acaban en el navegador y los límites de uso y gasto. Si no las has tocado, es probable que cualquiera pueda leer tus datos desde la consola del navegador. La infraestructura sobre la que se apoya Lovable es seria; lo que queda abierto son decisiones que nadie te pide mientras construyes.
¿Qué protege Lovable y qué tengo que proteger yo?
La plataforma se encarga del cifrado del tráfico, los servidores actualizados, el sistema de registro e inicio de sesión y las copias automáticas del servicio. Tú decides quién puede leer cada fila de tus tablas, qué claves llegan al navegador, si un usuario autenticado puede ver datos de otro, los límites de peticiones y de gasto, y tu cumplimiento del RGPD como responsable del tratamiento.
¿Qué es Row Level Security y por qué importa tanto?
Es el sistema de reglas por fila de Supabase, y es lo único que impide que un usuario pida la tabla entera cuando el navegador habla directamente con la base de datos. Durante el desarrollo estorba, así que la salida rápida es desactivarlo. Si se queda desactivado al publicar, cualquiera puede leer la tabla completa de clientes sin herramientas especiales.
¿Cuál es la diferencia entre la clave pública y la clave de servicio de Supabase?
La clave pública (anon key) está diseñada para vivir en el navegador y no da acceso por sí sola: depende de las reglas por fila. La clave de servicio (service role) se salta todas las reglas por diseño y solo debe existir en el servidor. Si un asistente la usa desde el lado del cliente para resolver un problema de permisos, esa clave viaja al navegador de todos tus usuarios y quien la copie tiene control total de la base de datos.
¿Cumple el RGPD una aplicación hecha con Lovable?
La plataforma cumple lo suyo; tú eres responsable del tratamiento desde que alguien introduce su nombre y su correo. Eso exige saber en qué región se alojan los datos —muchos proyectos se crean por defecto en Estados Unidos y la región se elige al crearlos—, tener base legal para cada dato que pides, una política de privacidad que describa la aplicación real, poder atender un borrado sin entrar a mano en la base de datos, y contratos de encargado con los proveedores que tocan datos personales.
¿Qué comprobaciones debo hacer antes de abrir mi app a clientes?
Ocho: reglas por fila activadas y probadas con dos cuentas distintas; ninguna clave de servicio en el código del navegador; llamadas a modelos de IA y pagos pasando por el servidor; tope de gasto configurado; límite de peticiones en los formularios públicos; una restauración de copia de seguridad ya probada; datos alojados en la Unión Europea o base legal documentada; y avisos automáticos cuando algo falla.
¿Y si mi app solo la usamos internamente?
Si es un prototipo interno con datos ficticios y tres usuarios de tu propia empresa, publica sin más: el riesgo real en esa fase es construir algo que nadie quiere, no construirlo mal. La revisión completa se justifica cuando hay clientes reales, datos personales o cobros de por medio.
¿Pasa lo mismo con Bolt, v0, Replit o Cursor?
Sí. Cambia la plataforma, no el reparto de responsabilidad. Todas optimizan para enseñarte algo funcionando cuanto antes, y lo que se sacrifica para conseguirlo es siempre lo mismo: control de acceso, gestión de claves y límites de uso.
Antes de abrirla a clientes, que alguien la mire
Cuéntanos qué has construido y con qué. Te decimos en 24 horas si está en condiciones de recibir usuarios reales o qué hay que tapar antes.
✓ ¡Recibido!
Gracias. Un especialista de Hiberus Booster te contacta en menos de 24 horas.
