Explosão de cobrança de €54.000 em 13 horas: chamadas à API Gemini feitas com chave de navegador do Firebase sem restrições de API

• A chave de navegador do Firebase foi exposta sem restrições de API, fazendo com que requisições à API Gemini fossem geradas automaticamente de fora, o que resultou em cobranças enormes em pouco tempo
• Foram cobrados mais de €54.000 em 13 horas, sem relação com o tráfego real de usuários, e os alertas de custo dispararam com atraso, atrasando a resposta
• A equipe de suporte do Google Cloud classificou essas requisições como uso válido (valid usage) e recusou o pedido de ajuste da cobrança
• O Google está introduzindo recursos de proteção como limites de gasto, chaves de autenticação, bloqueio automático de chaves e pagamento pré-pago, e pretende descontinuar gradualmente o uso de chaves irrestritas
• Desenvolvedores não devem incluir chaves no código do cliente e precisam aplicar restrições de chave de API e limites de orçamento obrigatoriamente

---

Caso de disparada de cobrança da API Gemini causada pela exposição de uma chave de navegador do Firebase

• Visão geral do incidente

  • Em um projeto que usava apenas Firebase Authentication, o uso da API Gemini disparou logo após a ativação do Firebase AI Logic
  • Requisições automatizadas sem relação com o tráfego real de usuários ocorreram em curto período, gerando cobranças de mais de €54.000 em cerca de 13 horas
  • Depois de desativar a API e rotacionar as credenciais (credential), o tráfego anômalo foi interrompido
  • O alerta de orçamento (€80) e o alerta de detecção de anomalias de custo foram acionados com várias horas de atraso; quando a resposta começou, os custos já estavam em torno de €28.000
  • O valor final cobrado foi confirmado em mais de €54.000 devido ao atraso no reporte de custos

• Resultado do suporte do Google Cloud

  • Apesar do envio de logs e materiais de análise, as requisições foram classificadas como uso válido (valid usage) originado no projeto, e o pedido de ajuste da cobrança foi recusado
  • Mesmo sendo um uso anômalo e não impulsionado por usuários, o sistema o tratou como cobrança normal

• Perguntas do usuário

  • Pergunta se existem casos semelhantes após ativar o Firebase AI Logic ou o Gemini
  • Pergunta se há medidas adicionais de proteção além de App Check, cotas e migração para chamadas server-side
  • Questiona se existe um caminho adicional de escalonamento (escalation path) para esse tipo de caso

Resposta do Google (Logan Kilpatrick)

• Funções de cobrança e limites de uso

  • Foram introduzidos limites de cobrança para usuários da API Gemini (billing account caps), e usuários Tier 1 são bloqueados automaticamente após o limite mensal de $250
  • É possível definir limites de gasto por projeto (project spend caps); como exemplo, contas pessoais podem ser limitadas a $50
  • Todos os relatórios de cobrança têm cerca de 10 minutos de atraso

• Segurança de chaves de API e mudanças

  • O uso de chaves de API sem restrições (unrestricted key) será desativado em breve na API Gemini

    • Para novos usuários, uma chave de autenticação (Auth key) é criada por padrão, em um formato mais seguro do que antes
    • Não inclua chaves no código do cliente; se forem expostas, isso pode gerar custos
    • Existe um recurso que detecta e desativa automaticamente chaves expostas na web pública, e já houve casos em que o bloqueio aconteceu em poucos minutos

• Restrições de chave e escopo de serviço

  • As chaves geradas no Google AI Studio são, por padrão, restritas apenas à API Gemini

    • Já as chaves criadas por outros caminhos, como o Google Cloud Console, podem acessar vários serviços, sendo necessário configurar restrições por serviço quando preciso

• Medidas adicionais e planos futuros

  • Para revisar o caso, foi solicitado contato direto por e-mail em [e-mail]
  • O sistema de cobrança pré-paga (prepaid billing) foi introduzido e está em transição para um modelo de pagamento antes do uso
  • No momento, isso já foi aplicado a novas contas nos EUA, com expansão gradual para o restante do mundo
  • Essas medidas têm como objetivo reforçar o controle de custos pelos desenvolvedores e evitar cobranças inesperadas

[GN⁺]

Comentários no Hacker News

• Nós configuramos alerta de orçamento (€80) e alerta de anomalia de custo, mas ambos dispararam com várias horas de atraso
  Quando reagimos, o custo já tinha chegado a €28.000, e no fim foram cobrados mais de €54.000 por causa do atraso no relatório de custos
  Nessa situação, a desculpa das três empresas de que “um teto rígido de gastos é tecnicamente impossível” não é convincente

  • Por isso eu evito ao máximo serviços como o Google Cloud
    Dizer que um teto rígido é impossível não faz sentido, e no mínimo o usuário deveria ter a opção
  • Isso é realmente absurdo. Você constrói um bom projeto e, por um único erro, acaba tendo que pagar €30.000~€50.000, o que é um golpe capaz de mudar a vida
    Antes esse tipo de erro era só um bug; agora pode levar à falência
  • Isso deveria ser ilegal
    Se você contratasse a troca dos azulejos do banheiro e cobrassem pela reforma do jardim, obviamente teria o direito de recusar
  • Como gerente, eu evito o Google Cloud por causa desse tipo de desastre de atendimento ao cliente
    Mas, tendo lidado com sistemas de cobrança de telecom, eu entendo que agregar logs em escala de TB leva tempo
    Ainda assim, operadoras normalmente consideram de 2~3% de inadimplência e tratam o cliente com mais cuidado
    O Google também deveria ter uma resposta mais elegante nessas situações
    Principalmente se isso aconteceu logo depois de uma chave de IA ter sido exposta, o Google deveria ter detectado o vazamento e bloqueado a chave
  • Segundo a documentação da API Gemini, é possível definir limites mensais de gasto tanto no nível do projeto quanto da conta de faturamento
    Mas, na prática, essa funcionalidade parece não funcionar direito

• Eu também tive uma experiência parecida
  Defini um orçamento de $100 no GCP, mas só recebi o alerta por e-mail 5 horas depois de ultrapassá-lo
  É surpreendente que esse tipo de recurso não seja prioridade
  No curto prazo, isso talvez preserve a receita do Google, mas um desenvolvedor que passa por isso nunca mais vai recomendar a plataforma

  • Toda vez que ouço histórias assim, fico com raiva
    Nosso time de 2 pessoas quase quebrou por causa de um runaway job
    Seguimos a recomendação do GCP e ligamos o alerta a um kill switch, mas o alerta chegou 6 horas atrasado
    No fim, só conseguimos reembolso depois de apresentar provas
    O Google disse que “havia itens demais na linha de cobrança e o pipeline atrasou”, mas não é justamente para esse tipo de situação que o sistema deveria existir?
  • Não consigo entender como um atraso em alertas pode ser aceitável
    Fico curioso para saber como acabou o acerto de custos com o Google
  • Na prática, a AWS também não trata isso como prioridade
    Nenhuma cloud corre para construir primeiro um recurso que corta a própria fonte de receita
  • A frase “trocar confiança de longo prazo por lucro de curto prazo” se encaixa perfeitamente
    É um retrato típico do capitalismo tardio

• Pelos resultados de busca no GitHub, há muitos casos em que tokens da API Gemini ficaram expostos em repositórios públicos
  O Google por muito tempo não tratou API keys como segredo, e só com chaves de LLM isso mudou de repente
  É bem provável que o autor tenha exposto a chave no frontend ou durante o compartilhamento de código

  • Esse problema já tinha sido relatado antes, e o Google disse que bloquearia chaves vazadas na API Gemini
    Isso também está indicado nesta thread relacionada no HN e na documentação oficial
    Então fica a dúvida de por que esse tipo de caso continua acontecendo
  • Na verdade, os resultados de busca não mostram chaves reais
  • Quando uma chave vazada é usada, aparece uma mensagem dizendo que ela foi invalidada
    “Your API key was reported as leaked. Please use another API key.”
    Ou seja, aparentemente a maioria é bloqueada automaticamente
  • Não faz sentido tratar API key como se não fosse segredo

• No Google Cloud não existe um jeito simples de configurar um teto rígido
  Eu mesmo passei mais de uma hora procurando a configuração e só descobri no Reddit o esquema Pub/Sub → Cloud Function → desativar faturamento
  É uma estrutura totalmente insana

  • Um teste de que eu gosto é pedir ao Gemini para “escrever um script que obtenha o uso de API do projeto”
    A taxa de falha é de 100%
  • Isso é praticamente uma armadilha para o usuário (antifeature)
  • Provavelmente é intencional
    Se a proteção montada pelo próprio usuário falhar, fica fácil dizer “não é responsabilidade nossa”
  • A ausência desse recurso significa que a empresa tem pouco incentivo para proteger o usuário
  • AWS e Azure são iguais nisso
    Seria ótimo se houvesse um recurso em que o kill switch fosse acionado automaticamente quando o uso passasse de um limite
    Cinco horas de downtime são aceitáveis, uma conta gigantesca não é

• Li este post e imediatamente fiz o downgrade do meu plano do Firebase
  Fiquei chocado ao ver um caso em que foram cobrados $6.909 por APIs que a pessoa nem chegou a chamar naquele mês
  Eu mesmo já criei uma API key durante uma sessão de ensino e pensei que talvez alguém pudesse até tê-la fotografado

  • Será que alguém realmente fotografou a chave naquela sessão? Fiquei curioso sobre a causa

• Em 2020~21, eu ensinava serviços de cloud para estudantes usando o AWS Free Tier
  Subi um servidor MediaWiki, mas contas de spam continuavam aparecendo e a segurança parecia instável
  Dava a sensação de que as portas de rede estavam sempre sob ataque
  No fim, percebi que não havia como limitar o orçamento a $20~30 e abandonei a AWS
  Mesmo que a cloud pareça prática de administrar, ela é perigosa tanto para indivíduos quanto para empresas por causa do risco de bombas de custo ilimitadas

• Para desenvolvedores solo ou equipes pequenas, a cloud pública é um ambiente assustador e inseguro
  Não há proteções suficientes, e os custos podem crescer sem limite
  Por isso, uma parte considerável do projeto acaba sendo gasta em monitoramento de custos e lógica de bloqueio
  Antes eu usava só VPS simples, mas hoje muitas vezes é preciso usar serviços do Google ou da AWS
  Ainda assim, sinto que o GCP é um pouco melhor por permitir desvincular programaticamente a conta de faturamento

  • Fico pensando no que acontece se a pessoa simplesmente não pagar
    Nos EUA provavelmente haveria problema legal, mas em outros países não sei como seria

• Esses sistemas de cobrança são muito mal projetados do ponto de vista de experiência do cliente (CX)
  A cobrança é baseada em eventos, então o uso entra em fila e a agregação atrasa
  Como os alertas também só saem depois da agregação, quando há atraso a conta já passou do limite há muito tempo
  Essa estrutura protege a empresa, não o cliente
  Se fosse realmente centrada no cliente, no momento em que o limite rígido fosse atingido nenhum valor acima disso seria cobrado
  Assim a empresa teria incentivo para melhorar o próprio sistema de agregação

  • Na verdade, o problema não é o modelo baseado em eventos em si
    Dá perfeitamente para fazer isso com cobrança pré-paga ou serviços com franquia de dados, debitando antes
    No fim, é uma questão de prática de negócio do Google

• Segundo a documentação oficial do Google Cloud, em caso de emergência é possível desativar a conta de faturamento para interromper a cobrança
  O guia oficial alerta para o risco de “perda irreversível de recursos”
  Mas, para apps de teste ou internos, isso funciona como um bom freio de emergência
  Vale também consultar outra documentação de alternativa e a documentação de configuração de alertas de orçamento

  • Só que pode haver atrasos de horas a dias entre a geração do custo e o alerta
    Eu já gastei $400 em apenas 5 minutos

• Nós também passamos pelo mesmo problema
  Uma chave que originalmente não era secreta passou a ser tratada como segredo depois da ativação da API Gemini, sem nenhum aviso
  Por sorte, percebemos cedo por causa de um alerta e o prejuízo ficou limitado a $26.000
  Pedimos reembolso ao suporte do Google, mas no começo foi negado; agora está em reavaliação
  Nesses casos, é preciso escalar o problema o máximo possível para níveis superiores