La programación asistida por Inteligencia Artificial ha acelerado prototipos, pequeñas aplicaciones internas y productos que antes tardaban semanas en llegar a una primera versión. El problema es que esa velocidad también está llevando a producción código que parece correcto, compila, responde bien en una demo y, aun así, arrastra fallos básicos de seguridad: credenciales expuestas, endpoints sin límites de uso, validación débil de entradas, errores demasiado detallados y permisos mal aplicados.
El fallo no está necesariamente en la IA. La IA escribe lo que se le pide, con el contexto que recibe y bajo las restricciones que se le imponen. Si un desarrollador le pide “créame una API para registrar usuarios”, puede recibir una API funcional. Pero si no le exige límites de intentos, validación server-side, gestión segura de secretos, control de autorización y cabeceras de seguridad, el resultado puede quedarse a medio camino entre un prototipo y una puerta abierta.
El llamado vibe coding ha popularizado una forma de construir software basada en iterar con un asistente hasta que algo funciona. Es útil para explorar ideas, aprender frameworks o acelerar tareas repetitivas. Pero en producción, “funciona” no equivale a “es seguro”. De hecho, muchos de los fallos más graves no rompen la aplicación. Siguen ahí, silenciosos, esperando a que alguien abuse de ellos.
El riesgo no es usar IA, sino desplegar sin criterio
Hay un patrón cada vez más común en proyectos creados con asistentes de código. La aplicación nace rápido, con una base razonable y una interfaz convincente. Después se conectan servicios externos, una base de datos, una pasarela de pagos, autenticación, correo transaccional o almacenamiento en la nube. En ese momento empiezan los problemas si nadie revisa cómo se están protegiendo credenciales, rutas, roles y entradas de usuario.
Un archivo .env subido por error a GitHub puede exponer claves de API, credenciales de base de datos o tokens de servicios cloud. GitHub ofrece protección frente a secretos precisamente para evitar que credenciales hardcodeadas lleguen al repositorio, mediante mecanismos como secret scanning y push protection, que bloquea pushes con secretos detectados antes de que se publiquen. Esa protección ayuda, pero no sustituye a una cultura básica de seguridad en el desarrollo.
El rate limiting es otro ejemplo claro. Un endpoint de login sin límite de intentos invita a ataques de fuerza bruta, credential stuffing o abuso automatizado. OWASP recomienda controles de limitación en autenticación, como número máximo de intentos o medidas equivalentes para frenar ataques repetidos. No es una sofisticación propia de grandes bancos: es higiene mínima para cualquier servicio expuesto a Internet.
La validación de entradas también suele quedar infravalorada. Muchos prototipos generados con IA validan en el frontend porque es lo más visible, pero dejan el servidor demasiado confiado. Esa es una mala práctica clásica. El navegador pertenece al usuario, y todo lo que llega al backend debe tratarse como no fiable: formularios, parámetros, cabeceras, ficheros, rutas, JSON, imágenes, nombres de archivo y cualquier dato procedente de clientes o integraciones.
Cinco revisiones antes de cualquier deploy
La primera revisión debe centrarse en límites de uso. Toda API pública o semipública necesita rate limiting adaptado a su riesgo. Las rutas de autenticación deben tener límites más estrictos, por ejemplo cinco intentos cada 15 minutos por IP o por combinación de IP y usuario, con respuesta 429 y cabecera Retry-After. Las rutas de lectura, escritura, subida de archivos o generación con IA también deberían tener cuotas, porque el abuso no siempre busca entrar: a veces busca agotar recursos o disparar costes.
La segunda revisión es el escaneo de secretos. El código debe analizarse para detectar claves, tokens, contraseñas, cadenas de conexión, certificados y credenciales de proveedores. El .env debe estar en .gitignore, pero eso no basta si ya se subió alguna vez. Hay que revisar también el historial de Git, bundles frontend, sourcemaps, logs, errores, variables expuestas en build y ficheros de configuración. Si una clave se filtró, la medida correcta no es borrarla del repositorio: es revocarla y emitir otra.
La tercera revisión afecta a la configuración sensible. Muchas aplicaciones modernas mezclan variables públicas y privadas. En frameworks frontend es fácil exponer por accidente variables que acaban empaquetadas en JavaScript. La regla debe ser simple: ningún secreto real debe llegar al cliente. Un fichero .env.example puede existir, pero solo con nombres de variables y valores ficticios. La configuración de producción debe gestionarse desde el entorno de despliegue o un gestor de secretos, no desde archivos compartidos alegremente.
La cuarta revisión es la validación server-side. Toda entrada debe validarse por tipo, tamaño, formato y contexto. Conviene rechazar payloads demasiado grandes, rutas sospechosas, extensiones no permitidas, campos inesperados y valores fuera de rango. Para bases de datos, las consultas parametrizadas deben ser la norma. Para HTML o contenido generado por usuarios, hay que controlar XSS. Para ficheros y rutas, hay que prevenir path traversal. Y para cualquier acción sensible, la validación del cliente solo debe ser una mejora de experiencia, nunca una barrera de seguridad.
La quinta revisión es una auditoría general antes del despliegue. Hay que revisar autenticación rota, autorización ausente en rutas, errores que muestran stack traces, dependencias vulnerables, cabeceras de seguridad, CORS demasiado abierto, cookies sin flags adecuados, falta de HTTPS, ausencia de CSP o HSTS, endpoints administrativos expuestos y logs que registran información sensible. OWASP sigue situando problemas como control de acceso roto, fallos criptográficos, inyección y configuración insegura entre los riesgos centrales de las aplicaciones web.
La IA también debe recibir prompts de seguridad
La parte práctica es que estos controles pueden incorporarse al propio flujo de trabajo con IA. No basta con pedirle al asistente que escriba una función; hay que pedirle que piense como revisor de seguridad antes de dar el trabajo por terminado. Un prompt útil no debería decir solo “haz una API”, sino “haz una API con rate limiting, validación server-side, autorización por rol, gestión segura de errores y pruebas de abuso”.
Para proyectos generados con IA, conviene introducir una fase obligatoria de revisión antes del despliegue. El asistente puede ayudar a recorrer rutas, detectar endpoints sin autorización, buscar secretos, proponer límites, revisar dependencias y generar pruebas. Pero el desarrollador tiene que saber qué pedir y verificar la respuesta. Delegar sin entender es una forma rápida de producir deuda de seguridad.
La responsabilidad final seguirá siendo humana. Si una aplicación expone una clave de Stripe, permite consultar datos de otros usuarios o acepta payloads maliciosos, al cliente afectado le importará poco que parte del código lo haya escrito un modelo. La IA puede acelerar, pero no firma el despliegue. Lo firma el equipo.
La buena noticia es que la seguridad básica no exige esperar a una auditoría anual. Puede integrarse en cada pull request, en cada pipeline y en cada sesión de trabajo con el asistente. Escaneo de secretos, análisis de dependencias, pruebas de autorización, validación de entradas, revisión de cabeceras y límites de uso deberían formar parte de la definición de “terminado”.
Programar con IA no debería rebajar el listón. Debería subirlo. Si el asistente permite escribir código más rápido, también debe usarse para revisar más, probar mejor y documentar los riesgos antes de que el software llegue a producción. El problema no es que la IA genere código inseguro. El problema es tratar el código generado como si estuviera listo solo porque parece funcionar.
Preguntas frecuentes
¿Es peligroso programar con Inteligencia Artificial?
No por sí mismo. El riesgo aparece cuando se despliega código generado o asistido por IA sin revisión de seguridad, pruebas y control humano.
¿Qué es rate limiting y por qué importa?
Es una limitación del número de peticiones permitidas en un periodo determinado. Sirve para reducir ataques de fuerza bruta, abuso automatizado, scraping agresivo y consumo excesivo de recursos.
¿Qué hago si he subido un .env a GitHub?
Borrarlo no basta. Hay que revocar las credenciales expuestas, generar nuevas claves, revisar el historial del repositorio y activar herramientas de detección y bloqueo de secretos.
¿Qué debe revisar un desarrollador antes de desplegar código generado con IA?
Rate limiting, secretos, variables de entorno, validación server-side, autorización, dependencias, cabeceras de seguridad, errores expuestos y permisos de acceso a datos.
