Vibe coding seguro: cómo evitar que la IA meta vulnerabilidades en tu código
El código que escribe la IA funciona casi siempre, pero no siempre es seguro: estudios de 2026 encuentran que entre el 40 % y el 60 % del código generado por modelos contiene alguna vulnerabilidad del OWASP Top 10. El problema no es la IA en sí —es excelente acelerando— sino aceptar lo que sugiere sin revisarlo. En esta guía te enseño qué fallos repite una y otra vez y la checklist exacta que debes pasar antes de hacer commit.
El vibe coding —programar describiéndole a un agente lo que quieres y aceptando lo que te devuelve— ha multiplicado por tres o cuatro la velocidad a la que escribimos código. El detalle incómodo: según un análisis sobre empresas Fortune 50, esos mismos desarrolladores introducen hallazgos de seguridad a un ritmo diez veces mayor que cuando escribían a mano. Más código, más rápido… y más superficie de ataque.
Por qué la IA genera código inseguro
Un modelo de lenguaje optimiza por una cosa: producir código que parezca correcto y que funcione para el caso feliz que le describiste. La seguridad casi nunca está en el prompt, así que tampoco está en la respuesta. La IA no «piensa» en el atacante que mete comillas en un formulario, en el usuario que cambia un id en la URL o en el secreto que acaba de escribir en texto plano.
A esto se suma la falsa confianza: el código compila, los tests del caso feliz pasan y la demo se ve completa. Parece terminado mucho antes de haber sido cuestionado de verdad. Y los números lo confirman: el 92 % de los desarrolladores ya usa IA a diario, pero solo el 29 % confía en el código que produce… y aun así apenas el 48 % lo revisa siempre antes de subirlo.
💡 La regla de oro. La IA es un junior brillante y rapidísimo que nunca ha leído el OWASP Top 10. Te ahorra horas, pero tú sigues siendo el senior que firma el commit. Si no entiendes una línea que sugirió, no la subas.
Las 7 vulnerabilidades que la IA mete una y otra vez
Estas son las que aparecen con más frecuencia en código generado por IA. Apréndetelas: revisar buscándolas concretamente es mucho más rápido que «leer todo a ver si algo huele mal».
1. Inyección (SQL y comandos)
El clásico. La IA concatena variables del usuario directamente en una consulta o en un comando del sistema porque es la forma «más corta» de escribirlo:
// ❌ Lo que sugiere la IA: inyección SQL servida en bandeja
db.query(`SELECT * FROM users WHERE email = '${email}'`);
// ✅ Lo correcto: consultas parametrizadas
db.query('SELECT * FROM users WHERE email = ?', [email]);
Lo mismo aplica a exec(), eval() y a construir comandos de shell con datos del usuario. Regla: si un dato entra desde fuera, nunca se interpola en una query o un comando; se pasa como parámetro.
2. Control de acceso roto (IDOR)
La IA implementa la lógica de negocio, pero olvida preguntar «¿este usuario tiene permiso para esto?». El resultado típico es un endpoint que confía en el id que le mandan:
// ❌ Cualquiera puede leer la factura de cualquiera cambiando el id
app.get('/api/facturas/:id', (req, res) => {
return res.json(getFactura(req.params.id));
});
// ✅ Comprueba la propiedad del recurso
app.get('/api/facturas/:id', requireAuth, (req, res) => {
const factura = getFactura(req.params.id);
if (factura.userId !== req.user.id) return res.sendStatus(403);
return res.json(factura);
});
Es la vulnerabilidad #1 del OWASP Top 10 y la que la IA pasa por alto con más naturalidad, porque «funciona» perfectamente en la demo.
3. Secretos hardcodeados
Para que «funcione ya», la IA te incrusta la API key, la contraseña de la base de datos o el token directamente en el código. Los commits asistidos por IA exponen secretos al doble de ritmo que los escritos a mano (3,2 % frente a 1,5 %).
// ❌ Un secreto en el repo es un secreto comprometido
const stripe = new Stripe('sk_live_51H...');
// ✅ Variables de entorno, siempre
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
Y recuerda: un secreto que tocó el historial de Git ya está quemado, aunque lo borres en el commit siguiente. Hay que rotarlo.
4. Dependencias alucinadas (slopsquatting)
Esta es nueva y peligrosa. Los modelos «inventan» nombres de paquetes que no existen: casi el 20 % de las muestras de código IA importan al menos una dependencia alucinada, y el 43 % de esos nombres falsos se repiten en cada ejecución. Los atacantes lo saben y registran esos nombres con código malicioso dentro, esperando a que alguien haga npm install a ciegas. Se llama slopsquatting.
Antes de instalar lo que la IA sugiere, verifica que el paquete existe de verdad, quién lo mantiene y cuántas descargas tiene. Si nunca habías oído ese nombre, desconfía.
5. XSS: salida sin escapar
La IA pinta en el HTML lo que el usuario escribió, sin sanitizarlo. Un estudio de Georgetown sobre cinco modelos grandes encontró XSS en la mayoría de las muestras analizadas.
// ❌ Si el comentario trae <script>, se ejecuta
<div dangerouslySetInnerHTML={{ __html: comentario }} />
// ✅ Deja que el framework escape, o sanea con DOMPurify
<div>{comentario}</div>
6. Criptografía débil
La IA arrastra patrones antiguos de sus datos de entrenamiento: hashear contraseñas con MD5 o SHA-1, usar Math.random() para generar tokens o cifrar con algoritmos rotos.
// ❌ MD5 para contraseñas: roto desde hace más de una década
const hash = crypto.createHash('md5').update(password).digest('hex');
// ✅ bcrypt / argon2 para contraseñas; random criptográfico para tokens
const hash = await bcrypt.hash(password, 12);
const token = crypto.randomBytes(32).toString('hex');
Si necesitas comprobar rápido qué algoritmo produce un hash, mi Generador de Hash MD5 y SHA te lo deja ver al instante —y de paso entiendes por qué MD5 no sirve para secretos.
7. Configuración insegura
CORS abierto a *, el modo debug encendido en producción, cookies sin HttpOnly/Secure, y casi siempre cero cabeceras de seguridad HTTP. La IA genera la app, pero no la endurece.
// ❌ CORS que acepta a cualquiera
app.use(cors({ origin: '*' }));
// ✅ Lista blanca explícita
app.use(cors({ origin: ['https://tudominio.com'] }));
Cuando termines tu app vibe-codeada, pásala por mi analizador de Cabeceras de Seguridad HTTP: te da una nota de la A a la F y te dice qué cabeceras (HSTS, CSP, X-Frame-Options…) te faltan. La mayoría de los proyectos generados por IA suspenden aquí sin saberlo.
La checklist: qué revisar antes de cada commit
No necesitas auditar línea por línea. Pasa este filtro mental —o pégalo en tu plantilla de pull request— sobre cada bloque que aceptes de la IA:
- Entradas del usuario → ¿toda query es parametrizada y todo comando evita la interpolación directa?
- Autorización → ¿cada endpoint que toca un recurso comprueba que este usuario puede verlo/editarlo?
- Secretos → ¿hay alguna clave, token o contraseña en el código? Fuera, a variables de entorno.
- Dependencias → ¿existe de verdad cada paquete nuevo? ¿Quién lo mantiene y cuántas descargas tiene?
- Salida → ¿se escapa o sanea todo lo que se pinta en el HTML?
- Criptografía → ¿contraseñas con bcrypt/argon2 y aleatoriedad con
crypto, nunca MD5 niMath.random()? - Configuración → ¿CORS cerrado,
debugapagado, cookies seguras y cabeceras de seguridad puestas?
Si trabajas con tokens, el Decodificador y Verificador de JWT te ayuda a confirmar que tu autenticación firma y caduca los tokens como debe, sin pegarlos en un sitio de terceros.
Automatiza la defensa: que la máquina revise a la máquina
Revisar a ojo no escala. Lo realista es poner redes de seguridad automáticas que corran en cada commit, para que el descuido no llegue nunca a producción:
- Escáner de secretos (Gitleaks, TruffleHog) en un pre-commit hook: bloquea el commit si detecta una clave.
- SAST (Semgrep, CodeQL, Snyk Code): análisis estático que caza inyección, XSS y control de acceso roto.
- Auditoría de dependencias (
npm audit,pip-audit, Dependabot): detecta paquetes vulnerables… y los inexistentes. - CI obligatorio: que ningún PR se fusione si falla cualquiera de los anteriores.
La regla de oro de 2026 con agentes: permisos mínimos y sandbox. Si dejas que un agente ejecute comandos, dale acceso solo a lo que necesita y en un entorno aislado. Un agente con permisos de administrador y una alucinación es una mala combinación.
La mentalidad correcta importa más que la herramienta
Toda esta tecnología sirve de poco si tu flujo es «aceptar todo y rezar». El cambio de mentalidad es simple: la IA propone, tú dispones. Trátala como a ese junior rapidísimo: revisas su trabajo, le exiges entender lo que entrega y eres tú quien responde por el código que se sube.
Si construyes apps móviles, los mismos principios se ordenan en el estándar OWASP MASVS —lo cubrí en mi guía de seguridad en aplicaciones móviles—. Y cuando ya tengas la app en un dominio, cierra el círculo auditando su correo, DNS y SSL con estas 7 herramientas gratuitas.
En resumen
El vibe coding llegó para quedarse y es una de las mayores mejoras de productividad de la década. Pero la velocidad sin revisión es deuda de seguridad disfrazada de progreso. La buena noticia: con la checklist de arriba, un par de escáneres automáticos y la mentalidad de revisar siempre, te quedas con toda la velocidad y casi ninguno de los riesgos.
¿Tienes una app que se construyó «a vibes» y no estás seguro de si es segura? Puedo revisarla o construirla bien desde la base: échale un ojo a mi servicio de desarrollo web a medida o, si quieres integrar IA en tu negocio sin abrir agujeros, a mi servicio de automatización e IA.
Preguntas frecuentes
¿Es seguro el código que genera la IA? Funciona, pero no es seguro por defecto: casi la mitad trae alguna vulnerabilidad del OWASP Top 10. Hay que revisarlo siempre antes de hacer commit.
¿Por dónde empiezo a revisar? Por las tres más graves y frecuentes: inyección (usa consultas parametrizadas), control de acceso (comprueba permisos en cada endpoint) y secretos hardcodeados (muévelos a variables de entorno).
¿Has pillado a la IA metiendo una vulnerabilidad en tu código? Cuéntame cuál fue —y si ya pasaste tu web por el analizador de cabeceras de seguridad, qué nota te salió.
