Uma chave de API do Google no frontend é um problema?

Abra seu app no navegador, veja o código-fonte da página e procure por AIza. Se aparecer uma sequência de quarenta caracteres, provavelmente alguém já disse que ela está "exposta", e provavelmente não disse o que fazer depois.

Aqui está a parte que a maioria dos conselhos sobre isso erra: uma chave de API do Google no seu frontend não é o mesmo tipo de problema que uma chave secreta do Stripe no seu frontend, e a correção não é escondê-la. Tratar as duas do mesmo jeito leva ou a entrar em pânico por causa do seu mapa ou, pior, a aprender a dar de ombros para a palavra "exposta" pouco antes do dia em que ela importa.

Entre 12 e 14 de agosto de 2026 rodamos as mesmas nove verificações externas em 30.998 apps no ar criados com Lovable, Bolt, v0, Replit e Base44. Uma chave de API do Google apareceu em 1.142 deles. Uma chave secreta do Stripe apareceu em três. Os números completos estão no nosso relatório de varredura.

É ruim que minha chave de API do Google esteja exposta no frontend?

Quase nunca. Depende inteiramente de a chave estar restrita ou não.

Uma chave de API do Google não é uma senha. Ela se parece mais com um número de conta: diz ao Google qual projeto cobrar e de qual cota descontar. Sozinha, ela não diz nada sobre quem está fazendo a requisição.

É por isso que ela pode morar na sua página. O mapa é desenhado pelo navegador do seu visitante, então é o navegador que precisa mandar esse número de conta ao Google. Não existe uma versão disso em que o mapa carrega e o número fica escondido.

A proteção vem de um segundo ajuste, guardado do lado do Google, que diz de quais sites o número pode ser usado. O Google chama isso de restrição de referenciador HTTP. Com ele definido, a chave impressa na sua página funciona no seu site e devolve um erro em qualquer outro lugar.

Por que seu app entrega a chave

Porque a requisição sai do navegador do seu visitante, não do seu servidor.

Quando alguém carrega uma página com um mapa, esse navegador fala direto com o maps.googleapis.com. Ele precisa dizer a qual projeto do Google a requisição pertence, e esse identificador precisa estar na página, porque a página é de onde a requisição parte.

O Google sabe disso. É por isso que a restrição existe como um controle separado: o identificador ia ser público de qualquer forma, então o que decide quem pode usá-lo mora em um lugar que o público não alcança.

Como restringir uma chave de API do Google

É grátis, leva cerca de cinco minutos e você não precisa mexer no código do seu app. No console do Google Cloud:

1. Vá em APIs e serviços → Credenciais e clique na chave que você achou.
2. Em Restrições de aplicativo, escolha Sites.
3. Adicione seu domínio. Para um site em yourapp.com, adicione https://yourapp.com/*. Adicione também seu domínio de prévia ou de teste, se você tiver um, e lembre do endereço .lovable.app ou .vercel.app em que seu app foi publicado antes de você ligar um domínio próprio.
4. Em Restrições de API, escolha Restringir chave e marque só as APIs que seu app chama de verdade. Um mapa com busca de lugares precisa da API JavaScript do Maps e da API Places, e nada mais.
5. Salve, espere alguns minutos, depois carregue seu próprio site e confira se o mapa ainda é desenhado.

Se o passo 3 estiver errado, você descobre na hora e de forma visível: o mapa falha com RefererNotAllowedMapError no console do navegador, o que nomeia o problema exato. Adicione o domínio que falta e volta a funcionar. É uma mudança reversível, e por isso vale a pena fazê-la antes de terminar de ler sobre ela.

Uma coisa para não fazer: as próprias orientações de solução de problemas do Google dizem que restrições por endereço IP são para chaves do lado do servidor e não servem para uma chave usada por um navegador. Se você restringir por IP uma chave do frontend, seu app quebra para todos os visitantes.

Se você prefere ver quais chaves seu app está de fato entregando antes de ir uma a uma, nossa varredura gratuita lê seu site no ar de fora e diz o que encontra. Leva cerca de 20 segundos e não precisa de conta: escaneie seu app.

Quais credenciais do Google cabem em um navegador

As três primeiras linhas são a mesma sequência. Uma chave de API do Google não traz escrito na frente para que serve, então a pergunta nunca é "com o que essa chave se parece" e sim "o que essa chave pode fazer", e essa resposta mora no console e não no seu código.

A chave do Firebase foi feita para ser pública

Essa é a linha sobre a qual mais perguntam, e a própria documentação do Firebase responde com clareza: chaves de API dos serviços do Firebase podem ficar no código ou em arquivos de configuração, porque elas não controlam o acesso a nada. Quem decide isso são as regras de segurança do Firebase e o App Check.

Se isso soa familiar, é o mesmo arranjo que o Supabase usa. A chave publicável identifica o projeto, e as regras por trás dela decidem linha por linha quem pode ler o quê. Nos dois casos a chave só é segura por causa dessas regras, então as regras são o que você deve ir olhar: ligá-las não é o mesmo que estar protegido.

O que acontece de fato quando vaza uma chave sem restrição

Uma conta, uma indisponibilidade ou as duas. Não um vazamento de dados.

Raspadores automáticos percorrem páginas públicas colhendo sequências AIza, e uma chave sem restrição funciona de qualquer lugar, então a sua acaba servindo blocos de mapa e buscas de lugares para o projeto de outra pessoa. O Google diz isso diretamente na própria documentação inicial: o motivo de definir restrições é impedir o roubo de cota.

Você normalmente percebe de uma de duas formas. A fatura vem maior que a do mês passado sem um motivo que você saiba apontar, ou os mapas do seu app param de ser desenhados no meio do mês porque o projeto esgotou a cota e cada visitante agora vê um retângulo cinza.

As duas têm conserto. Nenhuma expõe os dados dos seus usuários, porque uma chave do Maps não consegue ler seu banco de dados. Essa é a diferença honesta entre esse achado e uma chave de banco vazada, e é por isso que nosso scanner reporta uma chave de API do Google como algo a conferir e não como uma emergência.

A única credencial do Google que de fato se comporta como uma emergência é uma conta de serviço. Se seu app está entregando um arquivo JSON com "type": "service_account" e um bloco "private_key" dentro, isso é uma credencial de verdade com permissões de verdade no seu projeto na nuvem. Exclua a chave no console e depois veja o que ela conseguia alcançar.

O que fazer agora

Se você prefere resolver isso como uma lista, o checklist de segurança de 10 minutos cobre isso junto com as outras coisas que vale desligar em um app recém-lançado. E para a pergunta maior de quais chaves cabem em um navegador, temos um guia para distinguir chaves publicáveis das secretas.