Cómo Proteger Claves API de Extensiones VS Code Maliciosas

El 20 de mayo de 2026, GitHub confirmó que los atacantes robaron datos de aproximadamente 3.800 de sus repositorios de código 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 solo empleado. Una vez que esa extensión se ejecutó con los mismos permisos del sistema de archivos que el desarrollador, pudo leer todo a su alcance: código fuente, archivos de configuración y cualquier credencial que se encontrara en el espacio de trabajo. Si desea proteger las claves API de la misma clase de ataque, la lección es incómoda pero simple. El eslabón más débil rara vez es la nube. Es la máquina del desarrollador y las herramientas que se ejecutan en ella.

En resumen

Para proteger las claves API contra una extensión de IDE comprometida o un repositorio filtrado, deje de almacenar credenciales activas donde las herramientas de desarrollo puedan leerlas. Mantenga los secretos fuera del código fuente y de los archivos .env comprometidos. Trate .gitignore como una conveniencia, no como un control de seguridad. Alcance cada clave a un solo entorno, use credenciales de corta duración y con el menor privilegio, y rote según un cronograma. Herramientas como Apidog ayudan manteniendo las credenciales API en variables de entorno con valores solo locales en lugar de texto plano disperso por su repositorio y espacio de trabajo.

Por qué la brecha de GitHub es una llamada de atención para todo desarrollador

El incidente de GitHub se lee como un ataque de cadena de suministro de libro de texto. El grupo de amenaza, rastreado como TeamPCP, tiene un historial de troyanizar paquetes en los ecosistemas de npm, PyPI y PHP. Esta vez la carga útil maliciosa llegó en una extensión de VS Code. Según el informe de TechCrunch, los atacantes exfiltraron datos de aproximadamente 3.800 repositorios internos y ahora están vendiendo el conjunto de datos por más de 50.000 dólares en foros clandestinos. GitHub dice que no tiene pruebas de que los datos de los clientes almacenados fuera de esos repositorios internos se vieran afectados, y la investigación está en curso.

Aquí está la parte que debería hacerle detenerse. Una extensión de VS Code es solo código. Cuando instala una, se ejecuta dentro del proceso del editor con sus permisos de usuario. Puede listar archivos, abrirlos y leer su contenido. Puede vigilar los cambios de archivos. Puede realizar solicitudes de red salientes. Nada de eso es una vulnerabilidad; es el modelo de extensión funcionando según lo diseñado. La mayoría de las extensiones necesitan acceso a archivos para hacer su trabajo. El problema es que una extensión maliciosa o comprometida utiliza exactamente el mismo acceso para recolectar lo que encuentre.

¿Qué encuentra? En un proyecto típico, encuentra mucho. Un archivo .env en la raíz del repositorio. Un config/secrets.yml. Un token codificado en un script de prueba rápido que pretendía eliminar. Credenciales de AWS en ~/.aws/credentials. Un .npmrc con un token de autenticación. Claves SSH. El grupo TeamPCP es el mismo actor detrás de la campaña de gusanos de npm "Mini Shai-Hulud", que recolectó credenciales de desarrolladores, CI/CD, la nube y herramientas de IA de máquinas infectadas. El patrón es consistente: ejecutar código en la máquina de un desarrollador, luego buscar cualquier cosa que parezca una credencial.

Esto no es nuevo en su esencia, solo en su perfil. Escribimos sobre un patrón de exposición similar en nuestro desglose de las lecciones de seguridad de API de la brecha de Vercel, y la mecánica de la cadena de suministro se alinea estrechamente con lo que cubrimos en la guía de seguridad de la cadena de suministro de npm. El incidente de GitHub es la misma historia con un nombre más grande. Así que la pregunta que vale la pena hacerse hoy es directa: si una extensión maliciosa se ejecutara en su editor ahora mismo, ¿con qué se iría?

Las claves codificadas y los archivos .env comprometidos son una vulnerabilidad permanente

La mayoría de las fugas de credenciales no son sofisticadas. Son un desarrollador que pega una clave en el código "por ahora" y la olvida, o un archivo .env que se cuela en un commit. Ambos crean una vulnerabilidad que permanece en su repositorio indefinidamente.

Las claves codificadas son el pecado obvio. Ha visto código como este:

import requests

# Quick test of the payments endpoint
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())

Esa clave sk_live_ ahora forma parte del archivo. Está en su directorio de trabajo donde cualquier extensión puede leerla. Si el archivo se commite, la clave está en su historial de Git para siempre, incluso después de eliminar la línea en un commit posterior. Cualquiera que clone el repositorio, o cualquier herramienta que lo escanee, obtiene la clave.

Se supone que el archivo .env es la solución. La idea es sólida: mantener los secretos fuera del código, cargarlos en tiempo de ejecución. Un .env real se ve así:

# .env (se carga en tiempo de ejecución, nunca se debe enviar)
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

Esto es mejor que la codificación. Pero observe lo que no cambió. Ese archivo todavía vive en su espacio de trabajo, en texto plano, legible por cada proceso que ejecuta el editor. A una extensión maliciosa no le importa si sus secretos están en app.py o en .env. Ambos son archivos. Ambos están a un fs.readFileSync de distancia. El patrón .env resuelve el problema de "secretos en el historial de Git" solo si el archivo nunca se commite, y no hace nada en absoluto por el problema de "herramienta local comprometida".

El .env comprometido es el peor resultado. Es alarmantemente común. Un desarrollador agrega .env al proyecto, escribe claves reales en él y olvida ignorarlo antes del primer commit. O un compañero de equipo clona el repositorio, ve .env.example, lo copia a .env, rellena las claves de producción, y un git add . posterior lo incluye. Ahora las credenciales de producción están en el historial compartido de un repositorio que podría ser público, podría ser duplicado, o podría terminar en una brecha como la de GitHub. Profundizamos en el ángulo de la filtración de repositorios en nuestro artículo complementario sobre la documentación de API y la seguridad del repositorio de Git.

.gitignore no es un control de seguridad

Esto merece su propia sección porque el malentendido está muy extendido. Añadir .env a .gitignore se siente como cerrar la puerta con llave. No lo es. Es una nota adhesiva que dice "por favor, no tomes esto".

Esto es lo que realmente hace .gitignore. Le dice a Git que omita los archivos no rastreados que coinciden con un patrón cuando ejecuta git add. Ese es todo el alcance. Tiene tres modos de fallo que importan para la seguridad:

1. No hace nada con los archivos ya rastreados. Si .env fue comprometido una vez, antes de que usted añadiera la regla de ignorar, Git sigue rastreándolo. La regla de ignorar es silenciosamente anulada. Tiene que ejecutar git rm --cached .env y comprometer esa eliminación, y el secreto todavía está en cada commit histórico.
2. No hace nada con el archivo en disco. .gitignore es una instrucción de Git. El archivo .env todavía se encuentra en su directorio de trabajo en texto plano. Una extensión maliciosa de VS Code lee el sistema de archivos, no el índice de Git. Su regla de ignorar es invisible para ella. Este es el modo de fallo que más importa para el ataque al estilo GitHub.
3. Está a un error de ser omitido. git add -f .env ignora la regla de ignorar. Lo mismo ocurre si se añade el archivo a través de la interfaz de control de código fuente de un editor. También lo hace un .gitignore diferente en un subdirectorio que no repite el patrón.

Puede confirmar el punto uno usted mismo. Si sospecha que un secreto fue comprometido alguna vez, este comando se lo muestra:

# Lista cada commit que alguna vez tocó el archivo, incluso si ahora está "ignorado"
git log --all --full-history --oneline -- .env

# Vea los valores secretos reales que aún están en el historial
git log -p --all -- .env | grep -iE "key|secret|token|password"

Si eso devuelve algo, la credencial está comprometida en el momento en que el repositorio es expuesto. La solución no es una mejor regla de ignorar. La solución es rotar la clave y eliminar el archivo del historial con una herramienta como git filter-repo. La solución más profunda es asegurarse de que la credencial activa nunca estuvo en un archivo en primer lugar.

.gitignore sigue valiendo la pena usarlo. Detecta errores honestos y mantiene sus diferencias limpias. Simplemente no lo confunda con un límite que un atacante respete. Es higiene, no defensa.

Alcance, separe, acorte, rote: los cuatro hábitos que reducen el radio de impacto

No se puede garantizar que una credencial nunca se filtre. Pero se puede garantizar que una credencial filtrada es casi inútil. Cuatro hábitos hacen la mayor parte del trabajo.

Alcance los secretos a los entornos

Una clave filtrada debería desbloquear una sola cosa, no toda su propiedad. El fallo de alcance más común es usar la misma clave API en desarrollo, staging y producción porque era más fácil. Cuando esa clave se filtra, cada entorno cae a la vez.

Dé a cada entorno sus propias credenciales. Su máquina local usa una clave de desarrollo con acceso a un proyecto sandbox y datos de prueba. Staging usa una clave de staging. Producción usa una clave de producción que existe en exactamente un lugar y nunca se copia a un portátil. Si la clave de desarrollo se filtra a través de una extensión comprometida, el atacante llega a un sandbox con clientes falsos. Eso es una molestia, no un incidente.

Separe los entornos correctamente

La separación de entornos es más que tres valores de clave diferentes. Significa que los entornos no pueden interactuar entre sí. La base de datos de desarrollo es una base de datos diferente, no una réplica de lectura de producción. El proveedor de pagos de staging es el modo de prueba del proveedor, por lo que una clave de staging filtrada no cobra nada real. Las herramientas y los humanos no deberían poder apuntar una configuración de "desarrollo" a datos de producción con solo cambiar una variable.

Cuando la separación es real, la pregunta "¿de qué entorno provino esta clave?" tiene una respuesta clara, y esa respuesta le dice exactamente cuán grave es una fuga.

Utilice claves de menor privilegio y de corta duración

Dos propiedades deciden cuánto daño hace una clave robada.

Privilegio. Una clave debe tener el conjunto más limitado de permisos que su trabajo requiera. Una compilación de frontend que lee un catálogo de productos público necesita una clave de solo lectura con alcance a ese único recurso. No necesita acceso de escritura, no necesita acceso de facturación y ciertamente no necesita ser administrador. La mayoría de los proveedores de API admiten claves con alcance o tokens de grano fino; los propios tokens de acceso personal de grano fino de GitHub son un buen modelo. Si está considerando estilos de token, nuestra comparación de claves API frente a OAuth explica cuándo los tokens OAuth de corta duración superan directamente a las claves estáticas.

Vida útil. Una clave que expira en una hora es un premio pobre. Para cuando un atacante compra un conjunto de datos robado y llega a su clave, esta ya no funciona. Las claves estáticas que viven para siempre son lo opuesto: funcionan hasta que alguien se da cuenta, lo que a menudo lleva meses. Prefiera los tokens de corta duración emitidos bajo demanda. Cuando una clave de larga duración es inevitable, establezca la caducidad más corta que el flujo de trabajo tolere.

Rote según un cronograma, no por pánico

La rotación consiste en cambiar el valor de una credencial para que la antigua deje de funcionar. La mayoría de los equipos rotan solo después de una brecha, con prisa y bajo estrés. Ese es el peor momento para descubrir que su proceso de rotación no está documentado.

Rote según un calendario en su lugar. Elija un intervalo por clase de credencial; las claves de producción de alto privilegio mensualmente, las claves de menor riesgo trimestralmente. La rotación rutinaria hace dos cosas. Limita la vida útil de cualquier fuga que aún no haya detectado, ya que una clave robada hoy dejará de funcionar en el siguiente ciclo. Y mantiene la mecánica, actualizando el valor en cada entorno consumidor, practicada y aburrida. Cuando ocurre un incidente real, la rotación es un botón que ha presionado cincuenta veces, no un simulacro de incendio. Para un tratamiento más completo, consulte nuestro resumen de herramientas de gestión de claves API.

Mantenga las credenciales en variables de entorno de Apidog, no sueltas en su espacio de trabajo

Aquí está el enfoque honesto. Apidog ofrece una extensión de VS Code y un servidor MCP propio. El argumento no es "nuestra herramienta es inmune a la clase de ataque que afectó a GitHub". Ninguna herramienta del lado del cliente lo es. El argumento es sobre dónde residen sus secretos y cuán expuestos están cuando algo en su máquina se comporta mal.

Piense en el escenario realista. Está construyendo y probando API todo el día. Necesita un token de portador, una clave API, una cadena de conexión a la base de datos. El movimiento predeterminado es colocarlos en un archivo .env o un script para que su cliente pueda usarlos. Eso coloca las credenciales activas en archivos de texto plano en el espacio de trabajo, que es exactamente la superficie que una extensión maliciosa rastrea. El sistema de entorno de Apidog cambia dónde residen esos valores.

Variables de entorno en lugar de archivos de texto plano

En Apidog, usted almacena las credenciales como variables de entorno en lugar de texto suelto en su repositorio. Una solicitud referencia la variable por su nombre, como {{access_token}} en un encabezado Authorization, y Apidog la resuelve en el momento del envío. El encabezado en su definición de solicitud dice Bearer {{access_token}}, no Bearer sk-proj-aB3dEf.... El secreto literal no se encuentra en un archivo .env en la raíz del proyecto esperando ser leído.

Esto es importante por la misma razón por la que .env supera la codificación, llevado un paso más allá. La credencial ya no es una línea de texto plano en un archivo que se encuentra junto a su código fuente. Es un valor administrado dentro del cliente API, referenciado indirectamente.

Los valores locales mantienen los secretos en su máquina

Apidog traza una línea deliberada entre dos tipos de valor para cada variable. Existe un valor compartido, o inicial, que se sincroniza con los servidores de Apidog y es visible para su equipo. Y existe un valor local, o actual, que permanece en su máquina y nunca se sube. La guía oficial es explícita: ponga datos sensibles como tokens y contraseñas en el valor local para que nunca salgan de su cliente.

El efecto práctico es que un compañero de equipo que clona la estructura del proyecto obtiene el nombre y la forma de la variable, access_token, db_password y el resto, pero no su secreto real. Cada desarrollador rellena su propio valor local. El token de producción activo de nadie viaja con los datos del proyecto sincronizados, y no hay ningún archivo compartido de claves reales para filtrar.

Gestión y aislamiento de entornos

La gestión de entornos de Apidog se basa en el hábito de alcance de la sección anterior. Usted define entornos separados: Desarrollo, Staging, Producción, y cada uno lleva su propia URL base y su propio conjunto de valores de variables. Las variables tienen un alcance de entorno: solo los valores del entorno activo están en efecto, y cambiar de entorno cambia todo el conjunto de credenciales a la vez.

Esto le brinda aislamiento de entorno por construcción. Su variable payment_api_key contiene una clave de sandbox en Desarrollo y una clave de producción en Producción. Nunca edita una solicitud para moverse entre ellos; usted cambia el entorno. Debido a que los valores están vinculados al entorno, una credencial de desarrollo no puede terminar accidentalmente en una llamada de producción, y un secreto de producción nunca tiene que existir en su entorno de desarrollo local en absoluto. Un entorno de desarrollo filtrado expone valores de desarrollo. La producción permanece intacta.

Para equipos que necesitan un límite estricto: secretos de bóveda

Si su equipo necesita que los secretos de producción nunca lleguen al cliente API, el plan Enterprise de Apidog agrega una función de Secreto de Bóveda que obtiene secretos directamente de HashiCorp Vault, Azure Key Vault o AWS Secrets Manager. Apidog almacena solo la ruta y los metadatos de la bóveda. Los valores secretos reales se extraen bajo demanda, se cifran en el cliente local y nunca se comparten con los compañeros de equipo a través del proyecto. El hogar de la credencial sigue siendo el gestor de secretos dedicado, que es exactamente donde debería vivir una credencial de producción.

Para probar el flujo de trabajo de variables de entorno, descargue Apidog, cree un proyecto, abra la Gestión de Entornos y añada sus credenciales como variables de entorno con valores solo locales. Lleva unos minutos y saca los secretos activos de los archivos de texto plano que una extensión puede leer.

Una advertencia honesta. Mover los secretos a Apidog reduce la cantidad de credenciales de texto plano que residen en su repositorio y espacio de trabajo. No hace que su máquina sea inmune a una herramienta comprometida. La defensa en profundidad sigue aplicándose: audite las extensiones que instala, mantenga las claves de producción con el menor privilegio y de corta duración, y rote según un cronograma. Apidog se encarga de la parte de "dónde residen las credenciales". El resto sigue siendo su responsabilidad.

Conclusión

La brecha de GitHub es una señal clara. Los atacantes han descubierto que la máquina del desarrollador, con sus herramientas de confianza y sus archivos de configuración en texto plano, es un objetivo más fácil que cualquier servidor de producción. No se puede hacer que esa máquina sea perfectamente segura. Pero sí se puede asegurar que una extensión de IDE comprometida o un repositorio filtrado entregue muy poco a un atacante.

Empiece con una auditoría. Abra el repositorio en el que más trabaja y búsquelo por key, secret, token y password. Verifique si .env está en su historial de Git. Lo que encuentre, trátelo como expuesto: rótelo, luego mueva el valor activo a un lugar donde una herramienta extraviada no pueda leerlo. Descargue Apidog y coloque su próximo conjunto de credenciales API en variables de entorno en lugar de un archivo de texto plano. Para un contexto más amplio, nuestros artículos complementarios sobre herramientas API autoalojadas después de la brecha de GitHub y herramientas de gestión de claves API son buenas lecturas siguientes.

Preguntas frecuentes

¿Una extensión de VS Code puede realmente leer mi archivo .env y mis claves API?

Sí. Una extensión de VS Code se ejecuta dentro del proceso del editor con los permisos de archivo de su cuenta de usuario. Puede listar directorios, abrir archivos y leer su contenido, incluidos los archivos .env, archivos de configuración y archivos de credenciales como ~/.aws/credentials. Este es un comportamiento normal de la extensión, ya que muchas extensiones necesitan legítimamente acceso a archivos. El riesgo es que una extensión maliciosa o comprometida utilice el mismo acceso para recolectar secretos. Ese es el mecanismo detrás de la brecha de GitHub de mayo de 2026.

¿Es suficiente añadir .env a .gitignore para proteger las claves API?

No. .gitignore solo le indica a Git que omita los archivos no rastreados durante git add. No hace nada con los archivos ya comprometidos antes de que existiera la regla, y el secreto permanece en el historial de Git de todos modos. Tampoco hace nada con el archivo en el disco: el archivo .env todavía reside en su espacio de trabajo en texto plano, completamente legible por cualquier herramienta o extensión local. Trate .gitignore como una forma de prevenir errores honestos, no como un límite de seguridad.

¿Qué debo hacer si encuentro una clave API en mi historial de Git?

Trátela como comprometida de inmediato, incluso si el repositorio es privado. Rote la clave primero para que el valor expuesto deje de funcionar. Luego elimine el archivo del historial utilizando una herramienta como git filter-repo, y fuerce el envío del historial limpio después de coordinarse con su equipo. Finalmente, mueva la credencial activa de cualquier archivo de texto plano para que la misma fuga no pueda volver a ocurrir. Consulte nuestra guía de herramientas de gestión de claves API para prácticas continuas.

¿Cómo reduce mi exposición almacenar claves API en Apidog?

Apidog le permite almacenar credenciales como variables de entorno y referenciarlas por su nombre en las solicitudes, de modo que el secreto literal no se encuentra en un archivo .env de texto plano en su repositorio. Cada variable admite un valor solo local que permanece en su máquina y nunca se sincroniza con servidores o compañeros de equipo, que es donde la documentación recomienda mantener tokens y contraseñas. Las variables con alcance de entorno también mantienen separadas las credenciales de desarrollo y producción. Reduce la cantidad de secretos activos que se encuentran en archivos que una herramienta puede rastrear; no hace que su máquina sea inmune a una herramienta comprometida.

¿Apidog también tiene una extensión de VS Code y esto es un riesgo?

Sí, Apidog distribuye una extensión de VS Code y un servidor MCP. El punto de este artículo no es que cualquier herramienta sea inmune a los ataques de la cadena de suministro; ninguna herramienta del lado del cliente lo es. El punto es dónde residen sus secretos. Mantener las credenciales en variables de entorno con valores solo locales, o en una integración de bóveda, significa que menos claves de texto plano están expuestas si cualquier herramienta en su máquina, incluida la propia extensión de Apidog, se ve comprometida. La defensa en profundidad, la auditoría de extensiones, el menor privilegio y la rotación siguen siendo aplicables.

¿Cuál es la diferencia entre el alcance y la rotación de claves API?

El alcance limita lo que una clave puede hacer y dónde se aplica: una clave de desarrollo solo llega a un sandbox, y una clave de solo lectura no puede escribir. La rotación cambia el valor de una clave en un cronograma para que el valor antiguo deje de funcionar. El alcance reduce el daño que una clave filtrada puede causar; la rotación reduce la ventana de tiempo en que una clave filtrada sigue siendo útil. Usted quiere ambas. Usadas juntas, una clave robada desbloquea poco y expira pronto.

¿Con qué frecuencia debo rotar las claves API?

Rote según un cronograma fijo en lugar de solo después de un incidente. Una base razonable es mensual para credenciales de producción de alto privilegio y trimestral para claves de menor riesgo, ajustada a su tolerancia al riesgo y a cualquier norma de cumplimiento. La rotación programada limita la vida útil de las fugas que no haya detectado y mantiene el proceso de rotación bien practicado, de modo que un incidente real sea rutinario en lugar de un caos.

¿Las claves API de producción deberían estar alguna vez en el portátil de un desarrollador?

Idealmente, no. Una credencial de producción debe existir en la menor cantidad de lugares posible, normalmente un gestor de secretos dedicado y el tiempo de ejecución de producción, nunca copiada a la máquina de un desarrollador. Los desarrolladores deben trabajar con credenciales de desarrollo o staging con alcance a datos no productivos. Si un portátil se ve comprometido, el atacante llega a un sandbox, no a sistemas de clientes activos. El aislamiento de entornos y la integración de bóvedas de Apidog apoyan esto al mantener los valores de producción fuera de los entornos de desarrollo locales.