DEV Community

Cover image for Cómo Proteger Claves API de Extensiones VS Code Maliciosas
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo Proteger Claves API de Extensiones VS Code Maliciosas

#api #security #spanish #vscode

El 20 de mayo de 2026, GitHub confirmó que atacantes robaron datos de aproximadamente 3.800 repositorios internos. El punto de entrada no fue un zero-day en los servidores de GitHub: fue una extensión de VS Code envenenada instalada en el portátil de un empleado. Al ejecutarse con los mismos permisos del desarrollador, la extensión pudo leer código fuente, archivos de configuración y credenciales dentro del espacio de trabajo. La lección para proteger claves API es directa: el eslabón débil suele ser la máquina del desarrollador y las herramientas que se ejecutan en ella.

Prueba Apidog hoy

En resumen

Para reducir el impacto de una extensión de IDE comprometida o de un repositorio filtrado:

  • No almacene credenciales activas en código fuente.
  • No confíe en archivos .env como límite de seguridad.
  • Use .gitignore solo como higiene, no como defensa.
  • Separe claves por entorno: desarrollo, staging y producción.
  • Aplique menor privilegio y credenciales de corta duración.
  • Rote claves según un cronograma.
  • Use herramientas como Apidog para mantener credenciales API en variables de entorno con valores locales, en lugar de dejarlas como texto plano dentro del repositorio.

Por qué la brecha de GitHub importa para cualquier desarrollador

El incidente de GitHub encaja con un patrón clásico de ataque de cadena de suministro. El grupo TeamPCP, conocido por troyanizar paquetes en ecosistemas como npm, PyPI y PHP, habría usado esta vez una extensión maliciosa de VS Code. Según TechCrunch, los atacantes exfiltraron datos de unos 3.800 repositorios internos y ofrecieron el conjunto por más de 50.000 dólares en foros clandestinos.

Una extensión de VS Code es código ejecutándose dentro del editor. Con los permisos del usuario puede:

  • listar directorios;
  • abrir archivos;
  • leer contenido;
  • vigilar cambios;
  • hacer solicitudes de red salientes.

Eso no es una vulnerabilidad por sí mismo. Es parte del modelo de extensiones. El problema aparece cuando una extensión maliciosa usa ese acceso para buscar secretos.

En un proyecto típico puede encontrar:

  • .env;
  • config/secrets.yml;
  • tokens pegados en scripts temporales;
  • ~/.aws/credentials;
  • .npmrc con tokens de autenticación;
  • claves SSH;
  • credenciales de servicios de IA, CI/CD o nube.

Ya vimos patrones similares en las lecciones de seguridad de API de la brecha de Vercel y en la guía de seguridad de la cadena de suministro de npm.

La pregunta práctica es esta:

Si una extensión maliciosa se ejecutara hoy en su editor, ¿qué secretos podría leer?

Claves codificadas y archivos .env: el problema real

La mayoría de las fugas de credenciales no empiezan con técnicas avanzadas. Empiezan con algo como esto:

import requests

# Prueba rápida del endpoint de pagos
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)

print(response.json())
Enter fullscreen mode Exit fullscreen mode

Problemas:

  1. La clave queda en texto plano.
  2. Cualquier extensión local puede leer el archivo.
  3. Si se commitea, queda en el historial de Git.
  4. Eliminar la línea después no elimina el secreto del historial.

El siguiente paso habitual es mover las claves a .env:

# .env
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
Enter fullscreen mode Exit fullscreen mode

Esto es mejor que codificar secretos en el código, pero no resuelve todo.

Un archivo .env sigue siendo:

  • texto plano;
  • legible por procesos locales;
  • accesible para extensiones del editor;
  • fácil de commitear por error;
  • peligroso si termina en un repositorio filtrado.

Una extensión maliciosa no distingue entre app.py y .env. Para ella ambos son archivos.

También analizamos este riesgo desde el punto de vista de repositorios filtrados en el artículo sobre documentación de API y seguridad del repositorio de Git.

.gitignore no es un control de seguridad

Agregar .env a .gitignore ayuda, pero no protege secretos.

Esto es lo que realmente hace:

.env
Enter fullscreen mode Exit fullscreen mode

Le dice a Git que ignore archivos no rastreados que coincidan con ese patrón cuando ejecuta git add.

Pero tiene tres fallos importantes.

1. No protege archivos ya rastreados

Si .env fue commiteado antes, Git seguirá rastreándolo aunque luego agregue la regla.

Para dejar de rastrearlo:

git rm --cached .env
git commit -m "Remove .env from repository"
Enter fullscreen mode Exit fullscreen mode

Pero el secreto seguirá en commits anteriores.

2. No protege el archivo en disco

.gitignore no cifra ni oculta el archivo. Solo afecta a Git.

El archivo sigue estando aquí:

./.env
Enter fullscreen mode Exit fullscreen mode

Una extensión de VS Code comprometida puede leerlo igual.

3. Se puede omitir fácilmente

Por ejemplo:

git add -f .env
Enter fullscreen mode Exit fullscreen mode

También puede ocurrir desde una interfaz gráfica del editor o por una configuración incompleta en subdirectorios.

Cómo comprobar si .env estuvo en el historial

Ejecute:

git log --all --full-history --oneline -- .env
Enter fullscreen mode Exit fullscreen mode

Para buscar posibles secretos:

git log -p --all -- .env | grep -iE "key|secret|token|password"
Enter fullscreen mode Exit fullscreen mode

Si aparece una credencial, trátela como comprometida.

Pasos recomendados:

  1. Rote la clave inmediatamente.
  2. Elimine el archivo del historial con una herramienta como git filter-repo.
  3. Fuerce el push solo después de coordinarse con el equipo.
  4. Mueva la credencial activa fuera de archivos de texto plano.

Cuatro hábitos para reducir el impacto de una fuga

No puede garantizar que una credencial nunca se filtre. Sí puede hacer que una credencial filtrada sirva de poco.

1. Alcance secretos por entorno

No use la misma clave en desarrollo, staging y producción.

Use claves separadas:

DEV_API_KEY      -> sandbox
STAGING_API_KEY  -> staging
PROD_API_KEY     -> producción
Enter fullscreen mode Exit fullscreen mode

Si se filtra una clave de desarrollo, el atacante solo accede a un sandbox con datos de prueba.

2. Separe entornos de verdad

Separar entornos no es solo cambiar una variable.

Debe implicar:

  • bases de datos distintas;
  • proyectos distintos en proveedores externos;
  • modo de prueba para pagos en staging;
  • datos no productivos en desarrollo;
  • credenciales que no funcionen fuera de su entorno.

Una configuración de desarrollo no debería poder apuntar a producción cambiando una sola URL.

3. Use menor privilegio y credenciales de corta duración

Una clave debe tener solo los permisos necesarios.

Ejemplo:

Frontend público:
- lectura de catálogo
- sin escritura
- sin facturación
- sin permisos administrativos
Enter fullscreen mode Exit fullscreen mode

Si el proveedor permite tokens de grano fino, úselos. Si puede usar OAuth con tokens temporales, mejor. La comparación entre claves API y OAuth explica cuándo los tokens de corta duración reducen mejor el riesgo que claves estáticas.

La vida útil también importa:

Token de 1 hora     -> poco útil para un atacante
Clave sin caducidad -> útil hasta que alguien la detecte
Enter fullscreen mode Exit fullscreen mode

4. Rote según un cronograma

No espere a una brecha para aprender a rotar claves.

Defina un calendario:

Producción de alto privilegio -> mensual
Claves de menor riesgo        -> trimestral
Enter fullscreen mode Exit fullscreen mode

La rotación programada ayuda porque:

  • limita la vida útil de fugas no detectadas;
  • convierte la rotación en una operación rutinaria;
  • reduce el caos durante un incidente real.

Para ampliar este punto, revise la guía de herramientas de gestión de claves API.

Mantenga credenciales en variables de entorno de Apidog

Apidog ofrece una extensión de VS Code y un servidor MCP. El argumento no es que una herramienta cliente sea inmune a ataques de cadena de suministro. Ninguna lo es.

El punto práctico es reducir cuántos secretos quedan como texto plano en su repositorio o espacio de trabajo.

Cuando prueba APIs, normalmente necesita:

  • bearer tokens;
  • claves API;
  • cadenas de conexión;
  • passwords;
  • secretos de firma.

El error común es ponerlos en .env, scripts o archivos de configuración. Eso los deja en una superficie que cualquier extensión comprometida puede rastrear.

Use variables en lugar de secretos en texto plano

En Apidog puede almacenar credenciales como variables de entorno.

En vez de escribir esto en una solicitud:

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
Enter fullscreen mode Exit fullscreen mode

Use una referencia:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

La solicitud conserva la estructura, pero no contiene el secreto literal.

Use valores locales para secretos

Apidog diferencia entre:

  • valor compartido o inicial;
  • valor local o actual.

El valor local permanece en su máquina y no se sincroniza con el equipo. Según la guía de Apidog, ahí deben ir tokens, contraseñas y otros datos sensibles.

Flujo recomendado:

  1. Cree una variable llamada access_token.
  2. Deje vacío o genérico el valor compartido.
  3. Agregue el token real como valor local.
  4. Referencie {{access_token}} en sus solicitudes.

Así, el equipo comparte la estructura de la API, pero no comparte secretos reales.

Separe credenciales por entorno

La gestión de entornos permite definir entornos como:

Desarrollo
Staging
Producción
Enter fullscreen mode Exit fullscreen mode

Cada entorno puede tener su propia:

  • URL base;
  • clave API;
  • token;
  • configuración.

Ejemplo:

Desarrollo:
base_url = https://api-dev.example.com
payment_api_key = clave_sandbox

Producción:
base_url = https://api.example.com
payment_api_key = clave_produccion
Enter fullscreen mode Exit fullscreen mode

La solicitud no cambia. Solo cambia el entorno activo.

Esto reduce errores como llamar a producción con credenciales de desarrollo o copiar una clave de producción al entorno local.

Para equipos con requisitos estrictos: secretos de bóveda

Si las claves de producción no deben llegar al cliente API, el plan Enterprise de Apidog incluye Secretos de Bóveda.

La función permite obtener secretos desde:

  • HashiCorp Vault;
  • Azure Key Vault;
  • AWS Secrets Manager.

Apidog almacena la ruta y los metadatos, no el valor secreto como parte del proyecto compartido. Los valores se recuperan bajo demanda, se cifran en el cliente local y no se comparten con compañeros de equipo a través del proyecto.

Para probar el flujo básico:

  1. Descargue Apidog.
  2. Cree un proyecto.
  3. Abra la gestión de entornos.
  4. Agregue variables como access_token, api_key o db_password.
  5. Guarde los valores sensibles como valores locales.
  6. Use {{variable}} en sus solicitudes.

Esto no hace que su máquina sea inmune a una herramienta comprometida, pero reduce la cantidad de secretos activos expuestos como archivos de texto plano.

Checklist práctico para auditar su repositorio

Ejecute esta revisión en el repositorio donde trabaja con más frecuencia.

1. Busque secretos obvios 

grep -RniE "api[_-]?key|secret|token|password|authorization|bearer" .
Enter fullscreen mode Exit fullscreen mode

Excluya dependencias si hace falta:

grep -RniE "api[_-]?key|secret|token|password|authorization|bearer" . \
  --exclude-dir=node_modules \
  --exclude-dir=.git
Enter fullscreen mode Exit fullscreen mode

2. Revise archivos sensibles 

find . -name ".env*" -o -name "*.pem" -o -name "*.key" -o -name ".npmrc"
Enter fullscreen mode Exit fullscreen mode

3. Compruebe si .env estuvo en Git 

git log --all --full-history --oneline -- .env
Enter fullscreen mode Exit fullscreen mode

4. Si encuentra una clave, rótela

No intente decidir primero si alguien la vio. Trátela como expuesta.

Orden recomendado:

1. Revocar o rotar la clave.
2. Actualizar consumidores legítimos.
3. Limpiar historial si aplica.
4. Mover el secreto a un gestor o variable local.
5. Documentar el proceso.
Enter fullscreen mode Exit fullscreen mode

5. Verifique permisos

Para cada clave pregunte:

¿Qué puede hacer?
¿Dónde funciona?
¿Cuándo expira?
¿Quién la usa?
¿Dónde está almacenada?
Enter fullscreen mode Exit fullscreen mode

Si no puede responder, la clave necesita mejor gestión.

Conclusión

La brecha de GitHub muestra que los atacantes no siempre necesitan comprometer servidores de producción. A menudo basta con comprometer una herramienta de desarrollo y leer archivos locales.

No puede hacer que el portátil de un desarrollador sea perfectamente seguro. Pero sí puede reducir lo que un atacante obtiene si una extensión del IDE o un repositorio se ve comprometido.

Empiece hoy:

  1. Busque claves en su repositorio.
  2. Revise el historial de Git.
  3. Rote cualquier secreto encontrado.
  4. Separe credenciales por entorno.
  5. Saque secretos activos de archivos de texto plano.
  6. Use variables locales o un gestor de secretos.

Puede descargar Apidog y mover su próximo conjunto de credenciales API a variables de entorno en lugar de dejarlas en .env.

Para seguir profundizando, revise también los artículos sobre herramientas API autoalojadas después de la brecha de GitHub y herramientas de gestión de claves API.

Preguntas frecuentes

¿Una extensión de VS Code puede leer mi archivo .env?

Sí. Una extensión se ejecuta con permisos del usuario dentro del editor. Puede leer archivos del espacio de trabajo, incluidos .env, archivos de configuración y credenciales locales como ~/.aws/credentials.

¿Basta con agregar .env a .gitignore?

No. .gitignore solo evita que Git agregue archivos no rastreados por defecto. No elimina archivos ya commiteados, no borra secretos del historial y no impide que una herramienta local lea el archivo en disco.

¿Qué hago si encuentro una clave API en Git?

Rótela inmediatamente. Luego limpie el historial con una herramienta como git filter-repo, coordine el cambio con el equipo y mueva la credencial activa fuera de archivos de texto plano.

¿Cómo reduce Apidog la exposición de claves API?

Apidog permite guardar credenciales como variables de entorno y referenciarlas por nombre, por ejemplo {{access_token}}. Los valores sensibles pueden guardarse como valores locales, de modo que no se sincronizan con el equipo ni quedan en un archivo .env dentro del repositorio.

¿Apidog también tiene extensión de VS Code?

Sí. Apidog ofrece una extensión de VS Code y un servidor MCP. El punto no es que una herramienta cliente sea inmune, sino reducir la cantidad de secretos en texto plano disponibles para cualquier herramienta local comprometida.

¿Cuál es la diferencia entre alcance y rotación?

El alcance limita qué puede hacer una clave y dónde funciona. La rotación cambia el valor de la clave para que el anterior deje de servir. El alcance reduce el daño; la rotación reduce la ventana de exposición.

¿Cada cuánto debo rotar claves API?

Una base razonable es rotar credenciales de producción de alto privilegio mensualmente y claves de menor riesgo trimestralmente. Ajuste el intervalo según su riesgo, cumplimiento y capacidad operativa.

¿Las claves de producción deberían estar en portátiles de desarrolladores?

Idealmente, no. Las claves de producción deberían vivir en un gestor de secretos y en el runtime de producción. Los desarrolladores deberían usar credenciales de desarrollo o staging con datos no productivos.

Top comments (0)