Como proteger chaves API de extensões VS Code maliciosas

Em 20 de maio de 2026, o GitHub confirmou que invasores roubaram dados de aproximadamente 3.800 repositórios internos. O ponto de entrada não foi uma zero-day nos servidores do GitHub, mas uma extensão do VS Code comprometida instalada no laptop de um funcionário. Como a extensão rodava com as permissões do desenvolvedor, ela pôde ler arquivos do workspace, configurações e credenciais locais. A lição para quem trabalha com APIs é direta: proteja suas chaves assumindo que a máquina de desenvolvimento e as ferramentas instaladas nela podem ser comprometidas.

Experimente o Apidog hoje

TL;DR

Para proteger chaves de API contra extensões de IDE comprometidas ou repositórios vazados:

• Não armazene credenciais ativas no código-fonte.
• Não commite arquivos .env.
• Use .gitignore como higiene, não como controle de segurança.
• Separe chaves por ambiente: desenvolvimento, staging e produção.
• Use menor privilégio e credenciais de curta duração.
• Rotacione chaves em um cronograma.
• Mantenha segredos fora do workspace sempre que possível.

Ferramentas como o Apidog ajudam ao armazenar credenciais de API em variáveis de ambiente com valores apenas locais, em vez de espalhá-las como texto simples no repositório ou no diretório de trabalho.

Por que a violação do GitHub é um alerta para desenvolvedores

O incidente do GitHub segue um padrão comum de ataque à cadeia de suprimentos. O grupo de ameaças, rastreado como TeamPCP, já havia trojanizado pacotes em ecossistemas como npm, PyPI e PHP. Desta vez, a carga maliciosa chegou por meio de uma extensão do VS Code.

Segundo o relatório do TechCrunch, os invasores exfiltraram dados de cerca de 3.800 repositórios internos e passaram a vender o conjunto de dados por mais de US$ 50.000 em fóruns clandestinos. O GitHub afirma não ter evidências de que dados de clientes armazenados fora desses repositórios internos tenham sido afetados, e a investigação segue em andamento.

O ponto importante: uma extensão do VS Code é código executado dentro do editor com permissões do usuário. Ela pode:

• listar arquivos;
• abrir arquivos;
• ler conteúdo;
• observar alterações;
• fazer requisições de rede.

Isso não é uma vulnerabilidade por si só. É parte do modelo de extensões. O problema aparece quando uma extensão maliciosa usa esse acesso para procurar credenciais.

Em um projeto típico, ela pode encontrar:

• .env;
• config/secrets.yml;
• tokens hardcoded em scripts;
• ~/.aws/credentials;
• .npmrc com token de autenticação;
• chaves SSH;
• arquivos de configuração de ferramentas internas.

O mesmo padrão apareceu em campanhas anteriores, como o worm npm “Mini Shai-Hulud”, associado ao TeamPCP, que coletava credenciais de desenvolvedores, CI/CD, nuvem e ferramentas de IA em máquinas infectadas.

Esse tipo de exposição também se conecta a padrões abordados nas lições de segurança de API da violação da Vercel e no guia de segurança da cadeia de suprimentos npm.

A pergunta prática é: se uma extensão maliciosa rodasse agora no seu editor, quais segredos ela conseguiria ler?

Chaves hardcoded e arquivos .env commitados são riscos permanentes

A maioria dos vazamentos de credenciais não começa com um ataque sofisticado. Ela começa com algo simples:

• uma chave colada no código “só para testar”;
• um .env commitado por engano;
• um token salvo em um script temporário;
• uma credencial real usada em ambiente local.

Exemplo clássico de chave hardcoded:

import requests

# Teste rápido do endpoint de pagamentos
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())

Essa chave agora está:

• no arquivo local;
• visível para qualquer extensão com acesso ao workspace;
• possivelmente no histórico Git;
• disponível para qualquer pessoa ou ferramenta que clone ou escaneie o repositório.

Mover a chave para um .env é melhor do que hardcoding, mas não resolve tudo:

# .env
DATABASE_URL=postgres://app_user:[e-mail]: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

O .env evita que a credencial fique no código-fonte, mas o arquivo ainda está em texto simples no workspace. Para uma extensão maliciosa, não há diferença relevante entre ler app.py e ler .env.

O pior cenário é commitar esse arquivo. Isso pode acontecer facilmente:

cp .env.example .env
# preenche com chaves reais
git add .
git commit -m "configura ambiente local"

Agora as credenciais podem estar no histórico do repositório para sempre. Mesmo que você remova o arquivo em outro commit, o valor antigo continua disponível no histórico.

Para mais contexto sobre esse risco, veja o artigo sobre documentação de API e segurança de repositórios Git.

.gitignore não é controle de segurança

Adicionar .env ao .gitignore é necessário, mas não suficiente.

O .gitignore apenas instrui o Git a ignorar arquivos não rastreados durante operações como git add. Ele não protege o arquivo no disco e não remove segredos já commitados.

Principais falhas:

1. Não afeta arquivos já rastreados

Se .env já foi commitado, adicionar .env ao .gitignore não resolve. O Git continuará rastreando o arquivo.

Você precisaria executar:

   git rm --cached .env
   git commit -m "remove .env do controle de versão"

Mesmo assim, o segredo continuará no histórico.

1. Não protege o arquivo local

O arquivo .env ainda está no seu disco, em texto simples. Uma extensão comprometida lê o sistema de arquivos, não o índice do Git.

1. Pode ser ignorado manualmente

Um desenvolvedor ainda pode executar:

   git add -f .env

E commitar o arquivo apesar da regra.

Para verificar se .env já apareceu no histórico:

# Lista commits que tocaram o arquivo
git log --all --full-history --oneline -- .env

# Procura possíveis segredos no histórico
git log -p --all -- .env | grep -iE "key|secret|token|password"

Se houver retorno, trate a credencial como comprometida.

A correção deve incluir:

1. rotacionar a chave;
2. remover o arquivo do histórico com uma ferramenta como git filter-repo;
3. revisar onde o segredo ativo deve viver;
4. impedir que credenciais reais fiquem no workspace novamente.

Use .gitignore, mas entenda seu papel: ele previne erros simples. Ele não é uma fronteira de segurança.

Escopo, separação, expiração e rotação

Você não consegue garantir que uma credencial nunca será exposta. Mas consegue reduzir o impacto quando isso acontecer.

1. Delimite segredos por ambiente

Nunca use a mesma chave em desenvolvimento, staging e produção.

Use credenciais separadas:

dev     -> chave sandbox, dados falsos
staging -> chave de teste, ambiente isolado
prod    -> chave real, acesso mínimo necessário

Se uma chave de desenvolvimento vazar, o invasor deve alcançar apenas um sandbox.

2. Separe ambientes de verdade

Separar ambientes não é apenas trocar valores de variáveis.

Garanta que:

• o banco de desenvolvimento não seja réplica da produção;
• staging use modo de teste do provedor de pagamento;
• dados reais não estejam disponíveis em ambientes locais;
• uma configuração de dev não possa apontar facilmente para produção.

Quando a separação é real, você consegue responder rapidamente: “qual ambiente essa chave acessa?” e “qual é o raio de impacto?”.

3. Use menor privilégio

Uma chave deve ter apenas as permissões necessárias.

Exemplos:

• frontend público: somente leitura;
• job de relatórios: leitura apenas dos recursos necessários;
• integração de pagamento: acesso limitado ao provedor e ao ambiente correto;
• automação de CI: permissões específicas para build/deploy.

Evite chaves com privilégios amplos como padrão.

Se estiver decidindo entre chaves estáticas e tokens, a comparação entre chaves de API versus OAuth ajuda a avaliar quando tokens OAuth de curta duração são mais adequados.

4. Prefira credenciais de curta duração

Uma chave que expira em uma hora tem valor limitado para um invasor. Uma chave que nunca expira continua útil até alguém perceber.

Quando possível:

• use tokens emitidos sob demanda;
• defina expiração curta;
• evite chaves permanentes;
• limite chaves long-lived aos casos realmente necessários.

5. Rotacione em um cronograma

Não espere uma violação para aprender a rotacionar credenciais.

Defina uma política simples:

produção de alto privilégio -> mensal
produção de baixo risco     -> trimestral
desenvolvimento/staging     -> conforme risco e uso

A rotação programada reduz a janela de exploração e mantém o processo praticado.

Um checklist mínimo de rotação:

1. Criar nova chave.
2. Atualizar consumidores.
3. Validar tráfego com a nova chave.
4. Revogar chave antiga.
5. Registrar data e responsável.

Para um panorama mais amplo, veja o resumo de ferramentas de gerenciamento de chaves de API.

Mantenha credenciais em variáveis de ambiente do Apidog

O Apidog possui extensão para VS Code e servidor MCP próprios. O ponto aqui não é afirmar que uma ferramenta cliente é imune a ataques de cadeia de suprimentos. Nenhuma é.

O ponto é reduzir onde os segredos ficam expostos.

Em um fluxo comum de desenvolvimento de APIs, você precisa de:

• token Bearer;
• chave de API;
• string de conexão;
• senha de serviço;
• segredo JWT.

O hábito comum é salvar tudo isso em .env, scripts ou arquivos de configuração. Isso coloca credenciais ativas em texto simples dentro do workspace.

O Apidog muda esse fluxo ao permitir que você use variáveis de ambiente gerenciadas no cliente de API.

Use variáveis em vez de texto simples

No Apidog, você pode armazenar credenciais como variáveis de ambiente.

Em vez de escrever o token diretamente no header:

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890

Use uma variável:

Authorization: Bearer {{access_token}}

A requisição referencia o nome da variável, e o Apidog resolve o valor no momento do envio.

Isso evita que o segredo literal fique salvo em um arquivo .env ou em uma definição de requisição versionada junto ao código.

Use valores locais para segredos

O Apidog diferencia valores compartilhados/iniciais e valores locais/atuais.

Na prática:

• valor compartilhado: pode sincronizar com o projeto e ser visível para a equipe;
• valor local: permanece na máquina do desenvolvedor e não é enviado.

Para tokens, senhas e chaves reais, use valores locais.

Assim, a equipe pode compartilhar a estrutura:

access_token
db_password
payment_api_key

Mas cada desenvolvedor preenche seu próprio valor local. O projeto não transporta os segredos reais.

Separe ambientes no Apidog

O gerenciamento de ambientes do Apidog permite definir ambientes como:

Desenvolvimento
Staging
Produção

Cada ambiente pode ter:

• URL base própria;
• variáveis próprias;
• credenciais próprias.

Exemplo:

Desenvolvimento:
  base_url = https://api-dev.example.com
  payment_api_key = chave_sandbox

Produção:
  base_url = https://api.example.com
  payment_api_key = chave_producao

Você não precisa editar a requisição para alternar credenciais. Basta trocar o ambiente ativo.

Isso reduz erros como usar chave de produção em testes locais ou enviar uma requisição de staging com credenciais reais.

Use Segredos de Cofre quando produção não deve tocar o cliente

Para equipes que exigem um limite mais rígido, o plano Enterprise do Apidog oferece o recurso de Segredo de Cofre.

Ele permite buscar segredos de:

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

Nesse modelo, o Apidog armazena o caminho e os metadados do cofre. Os valores reais são buscados sob demanda, criptografados no cliente local e não compartilhados com colegas pelo projeto.

Esse fluxo mantém credenciais de produção no gerenciador de segredos dedicado, que é onde elas devem estar.

Para testar o fluxo de variáveis, baixe o Apidog, crie um projeto, abra o Gerenciamento de Ambiente e adicione suas credenciais como variáveis com valores apenas locais.

Importante: mover segredos para o Apidog reduz credenciais em texto simples no workspace, mas não torna sua máquina imune a uma ferramenta comprometida. Continue auditando extensões, usando menor privilégio, separando ambientes e rotacionando chaves.

Conclusão

A violação do GitHub reforça um ponto prático: a máquina do desenvolvedor é um alvo valioso. Ela concentra código, ferramentas confiáveis, arquivos de configuração e credenciais locais.

Você não consegue tornar esse ambiente perfeitamente seguro, mas pode reduzir o que um invasor encontra.

Comece com uma auditoria simples:

grep -RniE "key|secret|token|password" .
git log -p --all | grep -iE "key|secret|token|password"

Depois:

1. identifique segredos expostos;
2. trate-os como comprometidos;
3. rotacione as chaves;
4. remova credenciais do histórico quando necessário;
5. mova valores ativos para um local mais seguro;
6. separe ambientes;
7. aplique menor privilégio;
8. defina rotação periódica.

Você também pode baixar o Apidog e mover seu próximo conjunto de credenciais de API para variáveis de ambiente com valores locais, em vez de mantê-las em arquivos de texto simples.

Para continuar, leia também sobre ferramentas de API auto-hospedadas após a violação do GitHub e ferramentas de gerenciamento de chaves de API.

FAQ

Uma extensão do VS Code pode realmente ler meu arquivo .env e minhas chaves de API?

Sim. Uma extensão do VS Code roda com as permissões da sua conta de usuário. Ela pode listar diretórios, abrir arquivos e ler conteúdo, incluindo .env, arquivos de configuração e credenciais como ~/.aws/credentials.

Esse acesso é normal para muitas extensões. O risco é uma extensão maliciosa usar o mesmo acesso para coletar segredos.

Adicionar .env ao .gitignore é suficiente?

Não. O .gitignore apenas impede que arquivos não rastreados sejam adicionados automaticamente pelo Git. Ele não protege o arquivo no disco e não remove segredos já commitados.

Use .gitignore, mas não dependa dele como controle de segurança.

O que fazer se eu encontrar uma chave de API no histórico do Git?

Trate a chave como comprometida.

Faça o seguinte:

1. rotacione a chave imediatamente;
2. remova o arquivo ou valor do histórico com git filter-repo ou ferramenta equivalente;
3. coordene o force push com a equipe;
4. mova a credencial ativa para fora de arquivos em texto simples;
5. revise permissões e escopo da nova chave.

Veja também o guia de ferramentas de gerenciamento de chaves de API.

Como armazenar chaves de API no Apidog reduz minha exposição?

O Apidog permite armazenar credenciais como variáveis de ambiente e referenciá-las por nome nas requisições. Assim, o segredo literal não precisa ficar em um arquivo .env dentro do repositório.

Variáveis também podem ter valores apenas locais, que permanecem na máquina do desenvolvedor e não sincronizam com colegas ou servidores do projeto.

Isso reduz a quantidade de segredos ativos em texto simples no workspace.

O Apidog também tem extensão para VS Code. Isso é um risco?

Sim, qualquer ferramenta cliente pode ser parte da superfície de ataque. O objetivo não é afirmar que uma extensão é imune, mas reduzir onde os segredos residem.

Manter credenciais em variáveis locais ou em integrações com cofre expõe menos chaves em texto simples caso alguma ferramenta local seja comprometida.

Qual é a diferença entre delimitar e rotacionar chaves?

Delimitar define o que a chave pode acessar. Por exemplo, uma chave de desenvolvimento acessa apenas sandbox, e uma chave somente leitura não pode modificar dados.

Rotacionar troca o valor da chave para que a anterior pare de funcionar.

Você precisa dos dois: escopo reduz o impacto; rotação reduz a janela de exploração.

Com que frequência devo rotacionar chaves de API?

Use um cronograma fixo. Um ponto de partida razoável:

produção de alto privilégio -> mensal
menor risco                 -> trimestral
desenvolvimento/staging     -> conforme uso e risco

Ajuste conforme requisitos internos, compliance e criticidade da credencial.

Chaves de produção devem estar em laptops de desenvolvedores?

Idealmente, não.

Credenciais de produção devem viver no menor número possível de lugares, normalmente em um gerenciador de segredos e no ambiente de execução de produção.

Desenvolvedores devem usar chaves de desenvolvimento ou staging com dados não produtivos. Se um laptop for comprometido, o invasor deve alcançar apenas um ambiente limitado.