Armaste la app en un fin de semana, el login funciona, los datos se guardan y ya le mandaste el link a tres amigos. Felicitaciones, de verdad. Ahora la parte incómoda: en la mayoría de apps hechas así, cualquier persona con la consola del navegador abierta puede leer la tabla de usuarios completa. No porque Lovable sea inseguro, sino por una configuración que la herramienta no te obliga a tocar.
Es el salto que separa el prototipo del producto, y el que trabajamos en los módulos de backend y despliegue del curso de desarrollo de aplicaciones con Lovable. Va el diagnóstico primero y el checklist después.
Qué tan común es el problema
Durante 2026 se reportó una filtración que alcanzó a más de veinte mil apps creadas con IA y dejó expuestos decenas de miles de registros de usuarios, con la misma causa en casi todos los casos: Row Level Security apagado en Supabase. Un análisis de repositorios públicos encontró que alrededor del 57% de los proyectos hechos con Lovable tenían al menos una tabla del esquema público sin RLS, frente a cerca del 22% en proyectos de Supabase sin rastro de herramientas de IA.
No es que la IA escriba código inseguro. Es que crea tablas y sigue adelante, y Supabase deja RLS desactivado por defecto en las tablas nuevas. Nadie apretó el botón equivocado: faltó apretar uno.
La anon key no es un secreto (y eso está bien)
La clave anónima que Lovable deja en el frontend es pública por diseño: cualquiera puede verla y no pasa nada, siempre que la base esté protegida. La puerta real no es la clave, son las políticas. Sin RLS, esa clave pública da acceso de lectura a todo. Con RLS y una política de tipo «cada usuario solo ve sus filas», la misma clave no sirve para nada.
La clave que jamás debe salir del servidor es la de servicio. Se ha visto más de una vez: alguien la pega en la configuración del proyecto para «que deje de dar error de permisos», y termina empaquetada en el JavaScript que descarga el navegador. Esa clave ignora todas las políticas. Si la expusiste, no basta con borrarla del código: hay que rotarla.
Compruébalo en cinco minutos
- ▸Entra al panel de Supabase y revisa la sección de advertencias de seguridad. Lista las tablas públicas sin RLS: si hay alguna, ya tienes tu tarea.
- ▸Abre tu app sin iniciar sesión, copia la clave pública del código fuente y pídele a la API la tabla de perfiles. Si te devuelve filas, estás publicando tu base.
- ▸Busca en tu repositorio cualquier cadena que empiece con «service_role», más claves de OpenAI, Stripe o lo que hayas conectado. Si aparecen fuera de las variables del servidor, rótalas hoy.
- ▸Crea dos usuarios de prueba y entra con cada uno. Si el usuario A ve algo del usuario B, la política está mal escrita aunque RLS figure activo.
Pedirle al modelo «hazlo seguro» devuelve casi siempre un «listo, ya apliqué buenas prácticas». Pídele la política concreta, léela y pruébala con dos cuentas. Es la diferencia entre creer y saber.
El checklist antes de publicar
- ▸RLS activo en todas las tablas, con políticas que comparen contra el usuario autenticado. Una tabla sin política es una tabla cerrada; una tabla con RLS y política abierta es peor que nada.
- ▸Secretos solo en el servidor. Las llamadas a APIs de pago van desde una función en el backend, nunca desde el navegador.
- ▸Validación del lado del servidor. Que el formulario valide el monto no impide que alguien mande otro por la API.
- ▸Límite de uso y de gasto. Si tu app llama a un modelo por cada clic, alguien va a hacer mil clics. Pon tope de peticiones por usuario y alerta de facturación.
- ▸Respaldos y migraciones versionadas. Vas a pedirle un cambio al modelo y te va a borrar una columna. Que exista el camino de vuelta.
- ▸Dominio propio, política de privacidad y un correo de contacto. Si vas a cobrar, esto no es opcional en ningún país de la región.
- ▸Registro de errores. Sin logs, el primer reporte de un bug va a ser «no me funciona» y no vas a poder hacer nada con eso.
Lo que esto significa para quien no programa
No es un argumento para volver a contratar tres meses de desarrollo. Lovable sigue siendo la forma más rápida de tener un producto funcionando y validarlo con usuarios reales. Lo que cambia es dónde pones tu atención: ya no en escribir pantallas, sino en entender quién puede ver qué. Esas dos o tres horas de aprender permisos y despliegue son las que convierten un demo bonito en algo que puedes cobrar sin perder el sueño.
El curso de desarrollo de aplicaciones con Lovable son 25 clases y 5 horas a tu ritmo, con un recorrido completo: prompting, frontend, backend con Supabase, integraciones y pagos, pruebas, depuración y despliegue, y un proyecto final que sale publicado. Cuesta USD 89 e incluye certificado. Si ya tienes tu app a medio hacer, entra directo a los módulos 4 y 6, que son los de esta conversación.
Si el proyecto creció y ya quieres salir del editor visual para tocar el código tú, el siguiente paso natural es Claude Code, y si lo que quieres es construir productos con IA de forma seria, la ruta AI Engineer es el camino largo pero el que paga.
Y si te sirve construir con otra gente mirando, en la Comunidad AI Builders hay un taller en vivo cada semana donde se arman y se rompen apps como la tuya.
