El vibe coding ha cambiado la manera en que se construyen aplicaciones. Herramientas como Cursor, GitHub Copilot o ChatGPT permiten a cualquier persona generar código funcional en cuestión de horas, sin años de experiencia en desarrollo. El resultado es impresionante: prototipos rápidos, interfaces limpias, lógica que funciona.
El problema es lo que no se ve. Ese código pasa a producción con vulnerabilidades que cualquier atacante con conocimientos básicos puede explotar en minutos. No porque la IA sea mala, sino porque las herramientas de IA están optimizadas para generar código que funcione, no código que sea seguro.
En este artículo analizamos las seis vulnerabilidades más habituales en proyectos de vibe coding, por qué aparecen y qué hacer para corregirlas antes de que alguien las encuentre por ti.
Por qué el vibe coding genera código inseguro
Antes de entrar en las vulnerabilidades concretas, es importante entender la raíz del problema. No es culpa de la IA en sí misma: los modelos de lenguaje están entrenados sobre millones de repositorios de código público, y gran parte de ese código tiene malas prácticas de seguridad.
Cuando le pides a Cursor "crea un endpoint para login", el modelo genera el código más probable basándose en lo que ha visto. Y lo que ha visto con más frecuencia no siempre incluye validación de entradas, protección contra timing attacks, límites de intentos o tokens seguros.
- La IA prioriza la funcionalidad sobre la seguridad porque eso es lo que se le pide.
- El código generado no tiene contexto del sistema completo, por lo que no puede razonar sobre superficies de ataque globales.
- Las validaciones de seguridad son invisibles en el output: el código funciona aunque no las tenga.
- El desarrollador que usa vibe coding frecuentemente no tiene formación en seguridad, por lo que no detecta los problemas.
- El ritmo de desarrollo es tan rápido que no hay tiempo para revisión crítica de cada bloque generado.
Las 6 vulnerabilidades más habituales en proyectos de vibe coding
1. Inyección SQL
Severidad: Crítica.
La inyección SQL ocurre cuando datos controlados por el usuario se insertan directamente en una consulta a la base de datos sin sanitizar. Un atacante puede modificar la consulta para acceder a datos que no debería ver, borrar registros o tomar control del servidor.
El código generado por IA frecuentemente produce consultas concatenando strings en lugar de usar consultas parametrizadas o un ORM correctamente configurado. Algo tan simple como buscar un usuario por nombre puede abrir una brecha crítica si se construye así: "SELECT * FROM users WHERE name = '" + input + "'".
Cómo detectarlo
Busca en el código generado cualquier concatenación de variables en strings SQL. Si ves comillas simples alrededor de variables dentro de una query, hay una vulnerabilidad. La solución es siempre usar consultas parametrizadas o un ORM que las gestione internamente.
2. Autenticación sin validar (Auth Bypass)
Severidad: Crítica.
Los sistemas de autenticación generados con IA suelen tener implementaciones incompletas. Los problemas más habituales son: tokens JWT con algoritmo "none" aceptado, contraseñas hasheadas con MD5 o SHA1 en lugar de bcrypt, ausencia de verificación del token en rutas protegidas, y sesiones que no expiran correctamente.
Un caso típico: la IA genera el endpoint de login correctamente, pero el middleware que protege el resto de rutas simplemente comprueba si existe un token, sin verificar su firma. Un atacante puede forjar un token y acceder a cualquier endpoint protegido.
Cómo detectarlo
Revisa cada ruta protegida y verifica que el middleware de autenticación valida la firma del token, no solo su existencia. Comprueba también el algoritmo de hash de contraseñas: debe ser bcrypt, Argon2 o scrypt, nunca MD5 ni SHA1.
3. IDOR: Acceso sin Autorización a Recursos Ajenos
Severidad: Alta.
IDOR (Insecure Direct Object Reference) es una de las vulnerabilidades más comunes y menos detectadas. Ocurre cuando una API expone identificadores de recursos (IDs de usuarios, pedidos, facturas...) sin comprobar que el usuario que hace la petición tiene permiso para acceder a ese recurso concreto.
La IA genera el endpoint GET /api/invoices/:id que devuelve una factura por su ID. El código comprueba que el usuario está autenticado, pero no comprueba que esa factura pertenece al usuario autenticado. Cualquier usuario puede ver las facturas de cualquier otro simplemente cambiando el número en la URL.
Cómo detectarlo
Revisa todos los endpoints que reciben un ID como parámetro. Para cada uno, comprueba que la query filtra tanto por el ID del recurso como por el ID del usuario autenticado. No basta con comprobar que el usuario tiene sesión iniciada.
4. Claves API y Secretos Expuestos en el Código
Severidad: Alta.
Al generar código con IA y en la prisa de hacer funcionar algo rápido, es extremadamente habitual que claves de API, tokens de acceso, credenciales de base de datos o secretos de JWT queden hardcodeados directamente en el código fuente.
Si ese código se sube a un repositorio de GitHub (incluso privado), las claves pueden quedar expuestas en el historial de commits para siempre. Herramientas automáticas escanean GitHub continuamente buscando exactamente esto.
| Tipo de secreto expuesto | Consecuencia potencial |
|---|---|
| Clave API de Stripe o PayPal | Cargos fraudulentos a tu cuenta |
| JWT secret hardcodeado | Cualquiera puede forjar tokens de autenticación |
| Credenciales de base de datos | Acceso completo y borrado de todos los datos |
| Clave API de OpenAI | Consumo de tu cuota y costes no autorizados |
| Token de acceso a servicios cloud | Control total sobre tu infraestructura |
Cómo detectarlo
Ejecuta herramientas como git-secrets o TruffleHog sobre tu repositorio. Revisa el historial completo de commits, no solo el estado actual del código. Si encuentras secretos expuestos, rótalos inmediatamente aunque elimines el commit.
5. XSS y CSRF
Severidad: Media a Alta dependiendo del contexto.
XSS (Cross-Site Scripting) ocurre cuando la aplicación renderiza HTML que contiene código malicioso enviado por un usuario. Si el frontend generado con IA usa innerHTML o dangerouslySetInnerHTML sin sanitizar el contenido, un atacante puede inyectar scripts que roben sesiones o redirijan a usuarios.
CSRF (Cross-Site Request Forgery) ocurre cuando una petición de un sitio externo se ejecuta con las credenciales del usuario sin que este lo sepa. Las APIs generadas con IA frecuentemente no incluyen tokens CSRF en formularios ni comprueban el header Origin en las peticiones.
Cómo detectarlo
Busca usos de innerHTML, dangerouslySetInnerHTML o document.write sin sanitización previa. Para CSRF, comprueba que los endpoints de mutación (POST, PUT, DELETE) validan tokens o el header Origin.
6. Rate Limiting Ausente
Severidad: Media.
El código generado por IA raramente incluye límites de peticiones en los endpoints. Sin rate limiting, un atacante puede intentar millones de combinaciones de usuario y contraseña (brute force), realizar ataques de enumeración de usuarios, agotar cuotas de APIs de pago que tu backend llama, o tumbar el servidor con una sobrecarga de peticiones.
Los endpoints más críticos sin rate limiting son: login, registro, recuperación de contraseña, cualquier endpoint que llame a una API externa de pago y endpoints de búsqueda.
Cómo detectarlo
Revisa si existe algún middleware de rate limiting en el proyecto. En Node.js, librerías como express-rate-limit resuelven esto en minutos. El endpoint de login debe tener un límite estricto de intentos por IP y por cuenta.
Un escenario real: qué ocurre cuando alguien explota estas vulnerabilidades
Imagina una startup que lanza su SaaS construido en dos semanas con vibe coding. El producto funciona, los primeros clientes están contentos, hay datos reales de usuarios en la base de datos.
Un atacante hace un reconocimiento básico. Encuentra el endpoint de login sin rate limiting. En 20 minutos, con un script sencillo, prueba las 10.000 contraseñas más usadas contra las cuentas que pudo enumerar. Entra en tres cuentas.
Una vez dentro, nota que los IDs de recursos en la URL son secuenciales. Cambia el ID en la URL y accede a los datos de otros usuarios. Descarga la base de datos de clientes completa. La startup tiene ahora una brecha de seguridad con datos personales expuestos, obligación de notificar a la AEPD en 72 horas, y posibles sanciones por incumplimiento del RGPD.
Este escenario no es hipotético. Es el patrón de ataque más habitual contra aplicaciones jóvenes construidas rápido. Y la triste realidad es que se puede evitar en su totalidad con una auditoría de seguridad antes del lanzamiento.
Si quieres aplicarlo en tu empresa, te preparamos una propuesta en menos de 24 horas.
Pedir presupuestoQué hacer antes de lanzar tu app a producción
- 1.Auditoría de código: revisa cada endpoint de la API buscando los patrones de vulnerabilidad descritos en este artículo.
- 2.Prueba de penetración básica: intenta explotar tu propia app antes de que alguien más lo haga.
- 3.Revisión de secretos: escanea el repositorio completo con herramientas automáticas de detección de credenciales.
- 4.Implementa rate limiting en todos los endpoints de autenticación y en los que llaman a APIs externas.
- 5.Verifica la autorización en cada endpoint: no solo si el usuario está autenticado, sino si tiene permiso para ese recurso concreto.
- 6.Configura cabeceras de seguridad HTTP: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security.
Conclusión
El vibe coding es una herramienta poderosa que ha democratizado el desarrollo de software. Pero la velocidad tiene un precio cuando se ignora la seguridad. Un prototipo que funciona no es lo mismo que una aplicación lista para producción.
Antes de poner datos reales de usuarios en tu app, antes de cobrar a clientes, antes de integrar pasarelas de pago, una auditoría de seguridad no es un lujo: es el mínimo necesario para operar de forma responsable.
En Automatizalo.net auditamos el código de proyectos vibe coding, identificamos todas las vulnerabilidades con su nivel de severidad y entregamos el código corregido. Si tienes un proyecto próximo a lanzar, contacta con nosotros antes de que lo haga alguien más.