Vulnerabilidades del vibe coding: cómo los sitios generados con IA abren brechas a los hackers

El vibe coding ha dado a millones de personas la posibilidad de crear aplicaciones sin saber programar: basta con describir la tarea en lenguaje corriente y la IA genera código funcional. Es cómodo, rápido y a menudo da un resultado excelente. Pero esta accesibilidad esconde un problema en el que la mayoría de los novatos ni piensa: la IA escribe código que funciona, pero no siempre seguro.

La historia de un sitio

Bob Starr, project manager del sector tecnológico, usó vibe coding para crear el sitio «Boomberg», una herramienta que mostraba de forma visual cuánto dinero de los impuestos de EE. UU. va a parar a las empresas tecnológicas. Quedó satisfecho con el resultado y lanzó el proyecto en abierto de inmediato. Así funciona precisamente el vibe coding: rápido, de la idea al producto, sin etapas intermedias.

Solo varios meses después, Starr descubrió algo alarmante: el código contenía una inyección SQL. Es una vulnerabilidad clásica en la que un atacante puede leer o modificar los datos de una base simplemente formulando una consulta especial. El fallo existía desde el lanzamiento; nadie lo había notado.

«Fue un descuido evidente por mi parte.

Un punto ciego total al adoptar una tecnología nueva. Y estoy seguro de que otros cometen el mismo error», admitió Starr en una conversación con The Verge.

Por qué la IA pasa por alto las amenazas

Las herramientas de programación con IA están optimizadas para una cosa: que el código haga lo que se le pide. Generan un resultado funcional con rapidez, pero la seguridad a menudo pasa a segundo plano o se ignora por completo.

El problema no es la calidad de la generación. El problema es que un usuario sin experiencia en desarrollo no sabe qué preguntas hacer. Un ingeniero con experiencia, tras escribir el código, comprobará siempre cómo llegan los datos a las consultas a la base, quién tiene acceso a las funciones administrativas y si se han colado secretos en el repositorio. Para la mayoría de los vibe coders, esas preguntas simplemente no surgen.

Vulnerabilidades típicas en proyectos de vibe coding:

• Inyecciones SQL: el código no sanea la entrada del usuario antes de pasarla a la base de datos
• Claves de API expuestas: los secretos acaban directamente en el código fuente
• Dependencias obsoletas: uso de bibliotecas con vulnerabilidades conocidas
• Endpoints desprotegidos: funciones administrativas sin comprobación de autorización
• Vulnerabilidades XSS: salida insegura de datos en el navegador

No conviene subestimar la escala

El vibe coding hace tiempo que dejó de ser un fenómeno de nicho. Cursor, GitHub Copilot, Replit y Lovable han atraído a decenas de millones de usuarios, muchos de los cuales programan por primera vez en su vida. Parte de esos proyectos son experimentos personales sin usuarios reales. Pero otra parte ya funciona en internet, procesa datos reales y está abierta a cualquiera.

Hay que entender que la vulnerabilidad que encontró Starr no es exótica. Las inyecciones SQL figuran en el OWASP Top 10 desde hace más de 15 años y siguen siendo uno de los problemas más comunes de las aplicaciones web. La IA las reproduce porque se entrenó con código que las contenía.

La historia de Bob Starr es reveladora precisamente porque no intentaba tomar atajos: simplemente no sabía qué había que comprobar. Y ahí está el principal riesgo estructural del vibe coding: no la mala intención, sino la ignorancia sistémica.

Qué significa esto

El vibe coding reduce la barrera de entrada al desarrollo, pero no elimina la responsabilidad por lo que publicas en la red. Si el proyecto procesa datos de usuarios o simplemente es accesible desde internet, una auditoría básica de seguridad es obligatoria. Pedir a la propia IA que revise el código en busca de vulnerabilidades, estudiar el OWASP Top 10 o encargar a un especialista una auditoría rápida ya es un buen comienzo.