Una app vibe-codeada puede funcionar perfectamente delante de ti y aun así estar totalmente abierta por dentro. Esa es la parte incómoda de la generación de apps con IA: la demo funciona, el cliente queda impresionado, y nada de eso te dice si la pantalla de inicio de sesión se puede eludir o si la base de datos queda expuesta a cualquiera que inspeccione una solicitud de red.
Los modelos de IA están entrenados para producir algo que parezca terminado. No están entrenados para preguntarse «quién más podría llegar a este endpoint». Ahí está la brecha donde vive la mayor parte del riesgo real en el software generado por IA, y rara vez se nota hasta que alguien va a buscarla.
Las cifras son peores de lo que la mayoría de los creadores asume
Investigaciones independientes sobre código generado por LLM respaldan esto con un dato concreto e incómodo: los modelos compilan código funcional con éxito en alrededor del 90 % de los casos, pero cerca del 45 % de ese código presenta al menos una vulnerabilidad del OWASP Top 10, cosas como verificaciones de inicio de sesión eludibles o fallos de inyección que permiten a un atacante manipular una consulta.
No es un caso aislado. Significa que casi la mitad de lo que una herramienta como Lovable, Bolt o Base44 genera para ti a partir de un prompt determinado tiene, desde el principio, una debilidad real y explotable. La app sigue «funcionando» en todos los aspectos visibles. La vulnerabilidad simplemente no se anuncia hasta que un usuario (o un atacante) la encuentra.
De dónde viene realmente el riesgo
Los fallos de seguridad en las apps generadas por IA tienden a agruparse en torno a unos pocos patrones repetitivos:
- Verificaciones de autenticación del lado del cliente. La IA implementa «este usuario tiene permiso para ver esta página» en el navegador en lugar de en el servidor. Como el código del navegador es totalmente visible y editable, cualquiera puede abrir las herramientas de desarrollador, invertir la verificación y entrar.
- Secretos codificados directamente. Los creadores no técnicos que hacen pruebas en local a menudo no saben gestionar bien los archivos
.env, así que las claves de API y las cadenas de conexión a la base de datos se escriben directamente en el código. Esos archivos luego terminan subidos a un repositorio público de GitHub sin que nadie lo note. - Reglas de base de datos demasiado permisivas. Para que un prompt funcione rápido, la IA configura el acceso a la base de datos de forma amplia en lugar de restringida. Si se compromete cualquier otra parte de la app, esa configuración totalmente abierta convierte un pequeño error en una filtración de datos completa.
- Conexiones OAuth con permisos excesivos. Configurar una integración como Google Calendar o Slack requiere definir los alcances (scopes) de OAuth a mano. Pedir demasiado acceso crea una responsabilidad; olvidar un alcance rompe la integración en silencio. En cualquier caso, el creador está tomando una decisión de seguridad de la que normalmente ni siquiera es consciente.
Nada de esto se ve en una demo. Se ve en una auditoría de seguridad, en la consola del navegador de un usuario curioso, o en una notificación de brecha de seguridad meses después.
Por qué «funciona» es la prueba equivocada
La trampa es que los generadores de apps con IA te recompensan por lanzar rápido, y los ciclos de retroalimentación rápidos te entrenan para probar solo el camino ideal. Recorres el flujo de registro, el panel carga, el formulario se envía, todo parece correcto. Nada de eso te dice si la acción CRUD detrás de ese formulario verifica quién hace la solicitud.
Probar la seguridad correctamente significa hacer otras preguntas:
- ¿Puede un usuario deslogueado acceder directamente a esta URL?
- ¿Puede el usuario A ver o editar los registros del usuario B cambiando un ID en la barra de direcciones?
- ¿Se aplican las verificaciones de rol en el servidor, o solo están ocultas en la interfaz?
- ¿Las integraciones conectadas por OAuth solicitan solo los alcances que realmente usan?
La mayoría de los creadores no técnicos no saben que deben hacer estas preguntas, y la mayoría de los asistentes de código con IA no las plantearán por su cuenta a menos que digas explícitamente «revisa esto por problemas de seguridad»; e incluso entonces, la solución es otro parche generado, no una garantía estructural.
La alternativa: infraestructura que no tienes que auditar
Este es el verdadero argumento para construir apps de negocio sobre una plataforma con la seguridad integrada desde la base, en lugar de generada en cada proyecto. Softr es un buen ejemplo del enfoque opuesto: la autenticación, los permisos por rol y las reglas de acceso a datos son funciones nativas de la plataforma, no código que la IA reescribe para cada app.
En concreto, eso significa:
- CRUD del lado del servidor por defecto. Las acciones de lectura/escritura en la base de datos se ejecutan en los servidores de Softr, no en el navegador, así que de entrada no hay ninguna verificación del lado del cliente que eludir.
- Permisos de rol visuales en lugar de RLS escrito a mano. Los grupos de usuarios y las restricciones de datos controlan quién ve y edita qué registros, configurados visualmente y verificados mediante suplantación en la vista previa, en lugar de estar enterrados en código de políticas de base de datos fácil de configurar mal.
- Conectores OAuth preverificados. Las integraciones con herramientas como Google Calendar, HubSpot y Stripe usan las aplicaciones de desarrollador ya aprobadas de Softr, así que los creadores nunca tocan alcances OAuth en bruto ni almacenan ellos mismos credenciales de terceros.
- Flujos de autenticación utilitarios listos de fábrica. El inicio de sesión, el restablecimiento de contraseña, el OTP y el registro restringido por dominio ya están construidos, así que no hay lógica de autenticación personalizada que una IA pueda implementar mal de forma sutil.
Eso no significa que las herramientas generadas por IA sean inadecuadas para todo. Para un proyecto personal, un prototipo interno que nadie fuera de tu equipo tocará, o una landing page estática, el perfil de riesgo es bajo y el vibe coding es realmente el camino más rápido. El cálculo cambia en el momento en que entran en juego usuarios reales, datos reales de clientes o inicios de sesión externos.
Qué revisar antes de lanzar
Si de todos modos vas a construir con una herramienta de IA que genera código, una lista corta es mejor que ninguna:
- Busca en el código (grep) claves de API y cadenas de conexión codificadas directamente antes de cualquier commit.
- Confirma que las verificaciones de control de acceso también estén duplicadas en el servidor, y no solo ocultas en el frontend.
- Revisa los alcances OAuth concedidos a cada integración conectada y elimina los que no se usen.
- Pide a una segunda persona, idealmente con conocimientos técnicos, que intente acceder a los datos de otro usuario adivinando o cambiando un ID en la URL.
Esa lista no hará que el código generado sea tan seguro como una infraestructura que nunca fue generada, pero atrapa los fallos que aparecen con más frecuencia. Para un portal, un CRM o una herramienta interna en la que personas reales iniciarán sesión con datos reales, la solución más duradera es elegir una base donde el trabajo de seguridad ya esté hecho, para que no sea una moneda al aire en cada prompt.