No hace falta ser un experto en seguridad para entender los fallos que más se repiten en el código que genera una IA sin que nadie lo revise después. Son errores básicos, no ataques sofisticados, y precisamente por eso son tan fáciles de evitar —si alguien sabe que hay que buscarlos.
Claves y contraseñas a la vista de cualquiera
El fallo más repetido, con diferencia: dejar la clave de conexión a la base de datos, la clave de un servicio de pago o la clave de un servicio de email directamente en el código que carga el navegador de cualquier visitante. La IA necesita esa clave para que la web funcione, y si nadie le indica explícitamente dónde debe y dónde no debe quedar visible, la coloca donde sea más simple que funcione, no donde sea más seguro que esté. Fue exactamente lo que ocurrió en el caso de Moltbook que analizamos hace unas semanas: la clave de la base de datos estaba a la vista en el JavaScript de la página.
Formularios que aceptan cualquier cosa
Un formulario de contacto, de registro o de búsqueda tiene que validar lo que recibe: que un email parezca un email, que un número sea un número, que un campo de texto no contenga código ejecutable. Sin esa validación, alguien puede enviar código malicioso a través de un campo de texto normal —lo que se conoce como inyección— y conseguir que ese código se ejecute en tu web o en el navegador de otro visitante. Investigaciones recientes de universidades que probaron varios modelos de IA generando código encontraron este tipo de fallo en la gran mayoría de las muestras analizadas, precisamente porque validar cada campo a fondo no es lo primero en lo que piensa una IA centrada en que el formulario “se vea bien y envíe el email”.
Paneles y páginas que nadie protegió
Un panel de administración, una página de gestión de pedidos o una zona privada de usuarios necesita comprobar, en cada visita, que quien entra tiene permiso para estar ahí. Es habitual que el código generado por IA cree esa página perfectamente funcional —se ve, se usa, hace lo que debe— pero sin esa comprobación de permisos detrás. Cualquiera que adivine o encuentre la URL entra directamente, sin usuario ni contraseña, porque nadie le pidió a la IA explícitamente que la protegiera y ella no lo dio por hecho.
Dependencias que nadie vuelve a mirar
Casi ningún proyecto se construye desde cero: la IA tira de librerías y paquetes ya existentes para resolver partes comunes —login, pagos, envío de emails—. Esas piezas reciben actualizaciones de seguridad constantemente porque se les van encontrando fallos, igual que a cualquier software. El problema no es usarlas, es que una vez el proyecto está publicado y “funciona”, nadie vuelve a comprobar si esas piezas se han quedado desactualizadas y con vulnerabilidades ya conocidas y documentadas públicamente —lo que las convierte en el objetivo más fácil de encontrar para cualquiera que las busque.
Ninguno de estos cuatro fallos requiere un ataque complejo para explotarse, y ninguno se nota usando la web con normalidad. Lo que sí hace falta es que alguien los busque expresamente, con una revisión de mantenimiento y seguridad antes de que los encuentre otra persona. Si quieres que revisemos tu caso: cuéntanos cómo está montada tu web.
Preguntas frecuentes
¿Estos fallos solo afectan a webs hechas 100% con IA?
No, pueden aparecer en cualquier desarrollo donde no se haya revisado a fondo la seguridad, con o sin IA de por medio. Lo que cambia con el vibe coding es la probabilidad: al saltarse la revisión humana por definición, estos fallos aparecen con mucha más frecuencia que en un desarrollo tradicional revisado.
¿Cómo se detecta una clave expuesta en el código?
Con una revisión técnica del código fuente que carga la web y de la configuración del servidor y la base de datos. No es algo que se vea navegando la web normalmente ni que detecte un usuario sin conocimientos técnicos, por eso hace falta que alguien lo revise expresamente.
¿Basta con cambiar la clave si se descubre expuesta?
Es el primer paso, pero no el único: hay que revisar también si esa clave ya se usó para acceder a algo sin permiso, y corregir la causa —por qué quedó visible—, no solo el síntoma. Cambiar la clave sin corregir la causa suele significar que el mismo problema vuelve a aparecer en el siguiente cambio o actualización.