- Há mais de 10 anos, o Google orienta que chaves de API não são segredos e podem ser expostas com segurança, mas após a ativação da API Gemini a mesma chave passou a ser um meio de autenticação sensível
- Chaves públicas usadas em Google Maps, Firebase etc. passaram a receber automaticamente permissão de acesso à API Gemini, tornando possível acessar dados privados e gerar cobranças com chaves expostas
- A Truffle Security confirmou que 2.863 chaves de API do Google em uso real estão expostas na internet, incluindo em parte chaves de serviços do próprio Google
- O Google reconheceu o problema e está introduzindo bloqueio de chaves vazadas, padrão dedicado ao Gemini e notificações de exposição, mas a revisão retroativa das chaves existentes ainda não foi concluída
- Este caso mostra o risco de expansão de privilégios de credenciais existentes causado pela integração de recursos de IA, e os desenvolvedores precisam verificar imediatamente se a API Gemini está ativada e se há exposição de chaves
Problema central
- O Google Cloud usa uma estrutura única de chave de API no formato
AIza..., que cumpre ao mesmo tempo dois papéis: identificação pública e autenticação sensível
- No passado, o Google afirmou explicitamente aos desenvolvedores que era seguro incluir a chave de API diretamente no código do cliente
- Até mesmo na checklist de segurança do Firebase constava a orientação de que “chaves de API não são segredos”
- Porém, quando a API Gemini é ativada, todas as chaves de API do projeto existente passam automaticamente a ter permissão de acesso aos endpoints do Gemini
- A ampliação de permissão acontece sem aviso, etapa de confirmação ou notificação por e-mail
- Isso gera dois problemas
- Expansão retroativa de privilégios (Retroactive Privilege Expansion): chaves públicas antigas do Maps passam a funcionar como credenciais de acesso ao Gemini
- Padrões inseguros (Insecure Defaults): ao criar novas chaves, a configuração padrão é “Unrestricted”, permitindo acesso a todas as APIs, incluindo Gemini
- Como resultado, milhares de tokens usados para cobrança se transformaram em credenciais reais de autenticação e ficaram expostos na internet
Cenários possíveis de ataque
- Um invasor pode copiar uma chave
AIza... do código-fonte de um site e acessar a API Gemini com uma simples requisição curl
- Com isso, o invasor pode
- Acessar dados privados (endpoints
/files/ e /cachedContents/)
- Gerar cobranças pelo uso da API Gemini
- Esgotar a cota e provocar indisponibilidade do serviço
- O ataque pode ser realizado sem invadir a infraestrutura da vítima, bastando extrair a chave de uma página web pública
Escala das chaves expostas
- A Truffle Security analisou o dataset Common Crawl de novembro de 2025 (cerca de 700 TiB) e encontrou 2.863 chaves de API ativas do Google
- Essas chaves eram usadas originalmente para serviços públicos como Google Maps, mas possuíam permissão de acesso ao Gemini
- Entre os afetados estão instituições financeiras, empresas de segurança, uma recrutadora global e o próprio Google
- Até o Google estava exposto ao mesmo risco estrutural
Caso de chaves internas do Google
- A Truffle Security demonstrou acesso à API Gemini usando uma chave incluída no código-fonte público de um site de produto do Google
- Essa chave estava pública desde antes de fevereiro de 2023 e originalmente era usada apenas para identificação do projeto
- Ao chamar o endpoint
/models, retornou uma resposta válida (200 OK), confirmando acesso a API sensível
- Em outras palavras, uma chave antes inofensiva adquiriu privilégios sensíveis sem qualquer intervenção do desenvolvedor
Linha do tempo do relato da falha e resposta
- 21 de novembro de 2025: relato enviado ao Google VDP
- 25 de novembro: o Google avaliou como “comportamento intencional”
- 1º a 2 de dezembro: após a Truffle Security apresentar o caso da chave interna do Google, a empresa reclassificou como bug e elevou a severidade
- 12 de dezembro: o Google iniciou a expansão do pipeline de detecção de chaves vazadas e medidas de restrição de acesso ao Gemini
- 13 de janeiro de 2026: o Google classificou a vulnerabilidade como “Single-Service Privilege Escalation (READ)”
- 2 de fevereiro: foi confirmado que a correção da causa raiz estava em andamento
Medidas posteriores do Google
- Em documentação oficial, o Google anunciou os seguintes planos de reforço de segurança
- Scoped defaults: novas chaves criadas no AI Studio permitirão apenas acesso dedicado ao Gemini
- Leaked key blocking: bloqueio automático do acesso à API Gemini para chaves vazadas
- Proactive notification: envio imediato de alerta ao usuário quando uma chave vazada for detectada
- Algumas melhorias já estão em andamento, mas a verificação retroativa das chaves já expostas e a notificação aos usuários ainda não foram concluídas
Guia de verificação para desenvolvedores
- Etapa 1: verificar em todos os projetos GCP se a Generative Language API está ativada
- Etapa 2: se estiver ativada, identificar nas configurações de chave de API as chaves marcadas como “Unrestricted” ou com Gemini incluído
- Etapa 3: verificar se essas chaves estão incluídas em código público ou em páginas web
- Chaves expostas precisam ser rotacionadas imediatamente
- Bônus: é possível usar a ferramenta TruffleHog para detectar automaticamente chaves reais com acesso ao Gemini
- Exemplo de comando:
trufflehog filesystem /path/to/your/code --only-verified
Conclusão
- Este caso mostra o risco estrutural de credenciais públicas existentes ganharem privilégios sensíveis com a adição de recursos de IA
- O Google reconheceu o problema e está respondendo, mas a importância de padrões seguros por padrão e de um design com separação de chaves voltou a ficar em evidência
- Desenvolvedores e empresas devem verificar imediatamente se a API Gemini está ativada e se há exposição de chaves
1 comentários
Comentários do Hacker News
A documentação do Google AI Studio recomenda publicar apps por meio de um proxy aberto
Esse método faz parecer que a chave de API está segura por estar atrás do proxy, mas na prática permite abuso de cobrança de IA
Até apps sem nenhuma funcionalidade de IA ficam expostos a modelos caros se o escopo da chave não for limitado manualmente
Esses apps vulneráveis podem ser encontrados facilmente só com buscas no Google, Twitter e Hacker News
A análise relacionada está resumida neste texto
O Google diz que bloqueia chaves vazadas, mas desde o início essas chaves não eram tratadas como segredo
O ideal teria sido impedir que todas as chaves criadas antes do lançamento do Gemini acessassem o Gemini
Se o sistema de detecção de vazamento gerar falsos positivos, existe o risco de bloquear até chaves legítimas do Gemini
No mínimo, seria preciso remover a permissão da Generative Language API de todas as chaves existentes, mas nem isso seria uma solução completa
No fim, talvez seja necessário remover essa permissão em massa de todas as chaves
Isso quebraria inúmeras aplicações e é um dos motivos de o Google não querer reconhecer o problema
Mais grave ainda é o fato de que as chaves expõem até contextos em cache e dados enviados por upload
Foi descoberto que chaves do Google hardcoded em imagens antigas do Android podiam de fato ser usadas com o Gemini
Algumas já estavam sendo usadas por muita gente e tinham limitação de taxa, mas algumas ainda funcionavam
Cerca de dois meses atrás, essas chaves passaram a ser consideradas vazadas e foram todas desativadas
Chaves criadas há muito tempo eram originalmente para serviços limitados, como Firebase ou Firestore
Mas, depois do lançamento do Gemini, o acesso ao Gemini foi ativado automaticamente também para chaves antigas, o que facilitou o abuso
Na prática, chaves públicas incluídas em arquivos APK acabaram virando chaves de acesso ao Gemini
Por exemplo, se o desenvolvedor X criar uma chave para Maps e outro desenvolvedor Y ativar o Gemini no mesmo projeto
a chave de X passa a ter permissão de acesso ao Gemini
Portanto, é preciso evitar reutilizar projetos e usar projetos GCP separados por serviço
Fica a dúvida de por que uma falha de segurança tão óbvia não foi barrada antes
Uma empresa grande como o Google deveria ter testes ou especificações padronizados para isso
Quanto maior e mais complexa a organização, mais aumentam esses pontos cegos de supervisão
mas eles continuaram obcecados apenas com problemas de inverter árvore binária
Esse caso lembra o uso indevido de SSN (número de seguridade social) no passado
Era para ser apenas um número de identificação simples, mas em algum momento começou a ser usado como chave de autenticação, e os problemas cresceram
É a mesma estrutura de fazer rápido e barato e acabar repassando o custo para o usuário
O Google ainda não parece ter conseguido resolver completamente esse problema
Foi um grande erro causado pela pressa em lançar o Gemini,
e corrigir isso exigiria desativar chaves existentes, com grande chance de quebrar fluxos de trabalho dos clientes
Também é um dano de imagem extremamente grave para o Google
Isso é um tipo de problema de expansão retroativa de privilégios
Você deixava uma chave antiga do Maps pública no site e, se outro desenvolvedor da equipe ativasse o Gemini,
essa chave pública virava imediatamente uma credencial de acesso ao Gemini
Como resultado, qualquer pessoa podia usar essa chave para acessar uploads de arquivos ou dados em cache
Usuários que seguiram a documentação antiga e usaram chaves públicas estão sendo prejudicados
Um atacante poderia roubá-la e causar uma explosão de custos de cobrança
Explicando de forma simples, milhares de chaves de API existentes deixaram de ser meros tokens de cobrança
e de repente passaram a ser credenciais de acesso ao Gemini
Chaves da Maps API foram originalmente projetadas para fornecer mapas aos usuários enquanto a cobrança ia para o meu cartão
O problema é que essas chaves agora também podem acessar o Gemini
Deveriam ter sido criados projetos internos separados para isolar as chaves,
mas, na pressa de publicar, usaram código gerado por LLM do jeito que saiu e, quando deu problema, culparam o Google
Também impressionou a pesquisa anterior da empresa de segurança que analisou esse problema
Por exemplo, no texto “Anyone can Access Deleted and Private Repository Data on GitHub”
eles revelaram um caso de vulnerabilidade de acesso a dados de repositórios deletados do GitHub
Mais uma vez, a análise deles foi de grande ajuda