No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Sat, 16 May 2026 16:26:50 +0800

La programación con IA reduce la barrera para crear software, pero también lleva muchos problemas de seguridad de ingeniería a principiantes y usuarios no técnicos.

Uno de los incidentes más comunes es subir a un repositorio público un API Key, Secret, Token, cadena de conexión a una base de datos o archivo .env. En local, estos archivos parecen simples configuraciones para que la aplicación funcione. En un repositorio público de GitHub, se convierten en credenciales que pueden ser escaneadas, llamadas y abusadas automáticamente.

Las fugas de secretos no son raras. El informe 2026 de GitGuardian indica que los commits públicos de GitHub en 2025 contenían unos 28,65 millones de nuevas credenciales hardcodeadas, y que las fugas de credenciales relacionadas con servicios de IA crecieron un 81% interanual. El problema ya no es solo descuido: la programación con IA, los prototipos rápidos y el alojamiento público están amplificando la escala.

Por qué los principiantes filtran claves con más facilidad

Muchos agentes de IA y pequeñas herramientas tienen dos “repositorios”: uno en el disco local y otro visible para todo el mundo en GitHub. El problema es que los principiantes a menudo no distinguen bien esa frontera.

Durante el desarrollo local, config.json, .env y settings.yaml pueden contener API keys. Después de ejecutar git add ., git commit y git push, esos archivos pueden subirse completos. Cuando el repositorio es público, los bots de escaneo no necesitan entender tu negocio: solo necesitan detectar un patrón de secreto.

La programación con IA agrava esto:

Los ejemplos generados por IA pueden poner OPENAI_API_KEY = "sk-..." directamente en el código fuente.
Para “hacer que funcione”, los principiantes tienden a hardcodear secretos en frontend, scripts o archivos de configuración.
Muchas plataformas de vibe coding despliegan aplicaciones directamente sin pasar por la protección de push de GitHub.
El usuario puede no saber qué archivos, APIs o permisos predeterminados existen dentro del proyecto generado por IA.

En resumen, la IA puede ayudarte a crear algo que funciona más rápido. No asume automáticamente la responsabilidad de seguridad.

`.gitignore` no es decoración

Git gestiona el historial de versiones, GitHub aloja el código y .gitignore le dice a Git qué archivos no deben entrar en ese historial.

Un proyecto básico de IA debería ignorar al menos:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

Pero .gitignore no basta. Solo evita que archivos no rastreados se añadan en el futuro. Si un archivo con secretos ya fue committeado, añadirlo después a .gitignore no lo elimina del historial.

Un hábito más seguro:

Crear .gitignore al inicio del proyecto.
Guardar API keys solo en variables de entorno o configuración local.
Proporcionar .env.example con placeholders, no secretos reales.
Ejecutar un escáner de secretos antes de hacer commit, como gitleaks, trufflehog o GitHub Secret Scanning.

Borrar el archivo no basta

Si una clave ya llegó a un repositorio público, la primera reacción no debería ser “borro el archivo y hago otro commit”. Primero revoca o rota la clave.

Git registra el historial. Aunque el último commit elimine el archivo, los commits antiguos, forks, clones, cachés y sistemas de escaneo pueden conservarlo. La documentación de GitHub también recomienda revocar o rotar contraseñas, tokens y credenciales como primer paso.

Orden recomendado:

Revoca la clave antigua en el panel del proveedor y genera una nueva.
Revisa facturación, registros de uso, IPs sospechosas y tráfico inusual.
Elimina secretos hardcodeados y usa variables de entorno o un gestor de secretos.
Limpia archivos sensibles del historial con git filter-repo o BFG.
Activa GitHub Secret Scanning y Push Protection.
Revisa CI/CD, plataformas de despliegue, funciones cloud y artefactos frontend por si contienen la clave antigua.

En servicios como OpenAI, Anthropic, DeepSeek, proveedores cloud, pagos, correo o bases de datos, una clave filtrada puede provocar algo más que una factura inesperada: lectura de datos, abuso del servicio, contaminación de la cadena de suministro o bloqueo de cuentas.

Los secretos reales no van en el frontend

Muchos principiantes ponen API keys en JavaScript del frontend porque la página funciona:

`1`	`const apiKey = "sk-xxxxxxxx";`

Eso equivale prácticamente a publicarlas. El código del navegador, las peticiones de red, los Source Map y los artefactos de build se pueden inspeccionar. Cualquier clave que deba ser secreta no debe aparecer en el cliente.

La forma correcta es que el frontend llame a tu propio backend, y que el backend lea variables de entorno y llame a la API externa:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

El servidor usa la variable de entorno:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

Esto mantiene el secreto en el entorno del servidor y evita exponerlo a todos los visitantes.

Vibe Coding no elimina la responsabilidad de seguridad

El problema del vibe coding no se limita a GitHub. Muchas aplicaciones se publican directamente desde plataformas de programación con IA a internet, sin revisión de código, escaneo de repositorio ni pruebas de seguridad tradicionales.

Investigaciones recientes de RedAccess encontraron una gran cantidad de activos públicos generados o alojados por herramientas de programación con IA, y algunos exponían datos corporativos, información personal o archivos internos. La lección es clara: cuando “se puede desplegar” se vuelve demasiado fácil, se olvida preguntar “¿debería ser público?”, “¿debería ser solo interno?” y “¿tiene control de acceso?”.

Antes de publicar una app generada por IA, pregunta:

¿Esta aplicación necesita realmente acceso público?
¿Tiene login, autenticación y separación de permisos?
¿Expone URLs de bases de datos, API keys, tokens o webhooks en el frontend?
¿Tiene límites de cuota, dominio, permisos y caducidad para APIs externas?
¿Puedes desactivar claves y revertir despliegues rápidamente tras un incidente?

El código generado por IA también necesita revisión de seguridad. Cuanto menos código hayas escrito personalmente, menos deberías asumir que es seguro.

Comprobaciones para hacer ahora

Empieza por tu cuenta de GitHub. Busca tu usuario junto con:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

Si encuentras una clave real, rota primero y limpia después. Si entró alguna vez en un repositorio público, trátala como filtrada.

Para futuros proyectos con IA, usa un proceso fijo:

Escribe .gitignore antes del código de negocio.
Usa .env.example para documentar las variables necesarias.
Pon todos los secretos en variables de entorno, no en el código fuente.
Da a las API keys permisos mínimos, cuotas y fechas de caducidad.
Activa GitHub Secret Scanning y Push Protection.
Pide a la IA una revisión de seguridad antes de publicar, pero no confíes solo en su conclusión.

El verdadero peligro de la programación con IA no es solo que escriba código incorrecto. Es que da a muchas personas, por primera vez, la capacidad de publicar rápidamente aplicaciones inseguras en internet. Escribir rápido no es el problema. Entregar secretos, datos y permisos sí lo es.

API Key on KnightLi Blog

No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Por qué los principiantes filtran claves con más facilidad

`.gitignore` no es decoración

Borrar el archivo no basta

Los secretos reales no van en el frontend

Vibe Coding no elimina la responsabilidad de seguridad

Comprobaciones para hacer ahora

Referencias

API Key on KnightLi Blog

No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Por qué los principiantes filtran claves con más facilidad

.gitignore no es decoración

Borrar el archivo no basta

Los secretos reales no van en el frontend

Vibe Coding no elimina la responsabilidad de seguridad

Comprobaciones para hacer ahora

Referencias

`.gitignore` no es decoración