Vibe coding: cómo auditar y asegurar una app hecha con IA

Una aplicación hecha con vibe coding se puede asegurar, pero no basta con pedirle a la IA que la revise: hay que auditar quién puede ver y cambiar cada dato, cómo se manejan las sesiones, dónde viven los secretos y cómo llega el código a producción. Lo explicamos con un caso real, anonimizado: una aplicación de gestión escrita en HTML y PHP con ayuda de IA que terminó reconstruida en TypeScript.

Qué es el vibe coding y por qué preocupa en producción

El término lo acuñó Andrej Karpathy en febrero de 2025 para describir una forma de programar en la que aceptas todo lo que propone la IA, no lees los cambios y pegas los errores en el chat hasta que desaparecen. Él mismo lo presentó como algo útil para proyectos de fin de semana que se pueden tirar.

El problema aparece cuando ese prototipo se queda y empieza a guardar datos personales, de clientes o de pagos. El código funciona, pero nadie revisó si es seguro.

Veracode puso a prueba a más de 100 modelos de lenguaje con tareas de programación en Java, Python, C# y JavaScript: el 45 % del código generado falló las pruebas de seguridad e introdujo vulnerabilidades del OWASP Top 10. En Java la tasa de fallo llegó al 72 %, y ante el cross-site scripting los modelos no se defendieron en el 86 % de los casos. El informe también encontró que los modelos más nuevos o más grandes escriben código que funciona mejor, pero no más seguro.

Señales de que tu app necesita una auditoría

Si tu aplicación cumple dos o más de estas condiciones y ya guarda datos personales, de clientes o de pagos, tiene los mismos síntomas que el caso de este artículo:

• Se hizo con IA y nadie leyó el código completo antes de publicarla.
• No tiene pruebas automáticas, o solo se prueba usándola a mano.
• Cualquier usuario con sesión puede ver o modificar registros que no le corresponden.
• Contraseñas, códigos o tokens se guardan tal cual en la base de datos.
• Las llaves y contraseñas de servicios viven en archivos del servidor o del repositorio.
• Publicar un cambio es copiar archivos al servidor, sin ninguna revisión automática.
• La sesión nunca se cierra sola, aunque la persona deje de usar la aplicación.

El caso: una app de gestión hecha en HTML y PHP

La aplicación manejaba la operación diaria de una empresa, con datos personales de sus clientes, aprobaciones internas y documentos. Se construyó pieza por pieza con ayuda de IA. Omitimos el nombre y el sector de la empresa a propósito.

Así estaba hecha cuando empezó la revisión:

• Un solo archivo PHP de unas 3.700 líneas hacía de enrutador para todos los endpoints de la API.
• Cada módulo era un archivo HTML enorme: el más grande pasaba de 18.000 líneas e incluía un script de más de 600 KB.
• No había pruebas. Antes de desplegar solo se comprobaba que el código no tuviera errores de sintaxis, y desplegar era subir los cambios y copiarlos al servidor.
• Los secretos vivían en archivos que se editaban a mano en el servidor.
• Existían dos backends, uno de demostración y otro de producción, que se mantenían iguales a mano y ya se habían desviado.
• Una protección del esquema descartaba en silencio los campos cuya columna no existía, así que se podían perder datos sin ningún error.

No todo estaba mal. Las consultas a la base de datos usaban sentencias preparadas y las contraseñas se guardaban con bcrypt. Por eso una auditoría tiene que mirar el código real y no asumir que todo lo generado con IA es inseguro.

Qué encontró la primera auditoría

La revisión de la app original encontró fallos que no se ven usando la aplicación, solo leyendo el código:

• El código con el que se aprobaban operaciones internas se guardaba en texto plano.
• El identificador de sesión en la base de datos era el mismo token del usuario: quien leyera esa tabla podía tomar cualquier sesión.
• No había cabeceras de seguridad ni límites de intentos en el inicio de sesión.
• Cualquier persona con sesión podía reemplazar o borrar los documentos que recibían los clientes, y el borrado era definitivo.
• Cualquier rol podía leer y modificar registros de cualquier cliente.
• Las sesiones no se cerraban por inactividad.

Cómo auditar una app hecha con IA

Una auditoría útil divide la aplicación en áreas y revisa cada una por separado, sin modificar nada mientras busca. En este caso fueron cinco.

• Accesos y rolesQuién puede ver, crear, cambiar y borrar cada dato.
• Datos sensiblesQué se guarda en claro, qué se cifra y qué queda en el navegador.
• Acceso y sesionesCódigos de acceso, intentos permitidos y cierre de sesión.
• ClienteArchivos subidos, contenido inyectado y datos en localStorage.
• Infraestructura y despliegueSecretos, red, copias de seguridad y qué se revisa antes de publicar.

Cada hallazgo se cerró con una prueba automática que fallaba antes de la corrección y pasaba después, para que el mismo error no pueda volver sin que alguien lo note.

1. 1DetectarRevisar el código de un área sin modificarlo y registrar el hallazgo con su severidad.
2. 2ReproducirEscribir una prueba que demuestre el fallo y verla fallar.
3. 3CorregirCambiar el código hasta que la prueba pase.
4. 4BlindarDejar la prueba en la suite para que el fallo no vuelva.

Si quieres empezar por lo básico del servidor y las dependencias, la checklist de seguridad para tu servidor y tus dependencias cubre ese frente paso a paso.

Parchear o reconstruir

Con una base sin pruebas, archivos de miles de líneas y dos backends desincronizados, cada corrección tenía riesgo de romper otra cosa. La decisión fue reescribir la aplicación en TypeScript, con pruebas automáticas desde el inicio e infraestructura en la nube definida como código.

La migración tuvo tres verificaciones:

• Paridad de rutas. Se compararon las 148 rutas de la API original con las 143 de la nueva y se revisó una por una cuáles no tenían equivalente.
• Datos verificados. La base se cargó en una sola transacción y se comparó registro por registro contra la copia original: cero filas perdidas en 23 tablas.
• Cambio controlado. El paso a producción se hizo por DNS y el repositorio antiguo quedó congelado.

App original

• Código de aprobación guardado en texto plano
• Token de sesión guardado tal cual en la base
• Sin límites de intentos ni cabeceras de seguridad
• Sesiones sin cierre por inactividad
• Sin pruebas y despliegue manual
• Secretos editados a mano en el servidor

Plataforma nueva

• Código guardado siempre como hash bcrypt
• La base guarda solo el hash del token
• Límites por usuario e IP y cabeceras HSTS y CSP
• Cierre por inactividad a los 15 minutos
• Lint, pruebas, tipos y auditoría de dependencias antes de publicar
• Secretos en un gestor de secretos con un permiso por secreto

Qué controles tiene ahora la plataforma

Estos son los controles que quedaron en la plataforma nueva:

• Códigos de acceso con límites. Cada código vence a los pocos minutos y tiene un número máximo de intentos y de envíos.
• Freno a la fuerza bruta. Un contador en la base de datos, que funciona aunque haya varias réplicas de la API, bloquea tras 5 intentos por cuenta y 50 por IP.
• Cifrado por campo. Los datos sensibles se cifran con AES-256-GCM antes de guardarse, con un identificador de llave que permite rotarla.
• Red privada. La base de datos no tiene acceso público: vive dentro de una red privada y la API se conecta sin una contraseña guardada.
• Copias de seguridad fuera del servidor. Se cifran y se envían a otro lugar cada día, con 30 copias diarias y 12 mensuales. En el simulacro de restauración, recuperar la base tomó poco más de 8 minutos.
• IA con datos mínimos. Cuando la plataforma usa IA, los nombres de las personas se reemplazan antes de enviar el texto al modelo.

La auditoría después de migrar

Reescribir tampoco basta. Tres semanas después del cambio, una nueva auditoría de la plataforma reconstruida encontró 34 hallazgos, y una segunda pasada sumó 29 más. Algunos ejemplos que ya están corregidos:

• Un administrador podía crearse una cuenta con más permisos que la suya.
• Los usuarios desactivados conservaban la sesión abierta.
• Se podía subir un archivo con apariencia de PDF que ejecutaba código en el navegador de quien lo abría.
• Al cerrar sesión quedaban datos personales guardados en el navegador.
• Cada cambio publicado llegaba a producción sin pasar por pruebas.
• Las dependencias tenían 3 vulnerabilidades críticas y 22 altas conocidas.

Si tu sitio está en WordPress, también te puede interesar por qué migramos de PHP a código.

Fuentes

• Post original de Andrej Karpathy sobre vibe coding, X
• We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests, Veracode
• 2025 GenAI Code Security Report, Veracode
• OWASP Top 10:2025, OWASP Foundation