A chave do seu banco está escrita na página
Toda página que o navegador abre entrega o próprio código pra quem pedir. Se a chave do seu banco está escrita ali, ela já não é só sua.
Tem um jeito rápido de ver o que o seu site conta sobre si mesmo. Abra ele numa aba, clique com o botão direito em qualquer lugar e escolha "exibir código-fonte da página". Aquilo que aparece não é um bastidor que você invadiu. É exatamente o que todo visitante recebe, porque é isso que o navegador dele precisa pra desenhar a página.
Agora procure nesse texto por palavras como key, token, secret ou apikey. Se alguma delas vem seguida de uma sequência comprida de letras e números, você acabou de achar o achado mais comum em app feito com IA.
Como ela foi parar ali
Você pediu uma coisa razoável. Salva isso no banco. Manda um e-mail quando alguém se cadastrar. Cobra no cartão. O assistente escreveu o código que faz, e o jeito mais rápido de esse código funcionar é a página falar direto com o serviço. Pra página falar com o serviço, a credencial precisa viajar junto com a página.
Ninguém foi descuidado. O app funcionou, a demonstração foi bem, e a parte que teria movido a credencial pra um servidor que ninguém lê era trabalho a mais que nunca foi pedido. É por isso que isso é tão comum: o atalho e o app funcionando são a mesma coisa.
Nem toda chave à vista é problema
Supabase e Firebase têm uma chave pública, feita pra viver na página mesmo. Ela só é inofensiva enquanto as regras de permissão estão ligadas, porque quem decide quem lê o quê é a regra, não a chave. A outra, a que tem service, secret ou admin no nome, passa por cima de toda regra por desenho. Essa nunca deveria ter saído do seu servidor.
O que dá pra fazer com ela
- Ler a sua tabela de clientes inteira: e-mail, telefone, endereço, o que mais estiver lá.
- Escrever nela: criar registro, mudar preço, apagar linha.
- Mandar e-mail no seu nome, quando a chave é de um serviço de envio.
- Gastar o seu dinheiro, quando a chave é de algo que você paga por uso.
Nada disso parece invasão por dentro. Não tem alarme, não tem login estranho, não tem nada no registro que chame atenção. Do ponto de vista do serviço, quem pediu tinha a chave, então quem pediu era você.
A chave diz quem está falando. A regra diz o que essa pessoa pode ver.
A regra que ninguém ligou
Nos bancos mais usados por quem constrói com IA, a permissão é uma camada separada da chave, e ela precisa ser escrita tabela por tabela. Tabela sem regra se comporta do jeito que foi configurada no primeiro dia, que costuma ser a coisa mais permissiva que deixa o seu app funcionar.
Essa é a parte que vale parar pra pensar. O padrão não é maldade nem defeito. É um ponto de partida que supõe que você vai voltar depois pra apertar. A maior parte dos apps nunca volta, porque nada muda na tela quando você não volta. A falha tem nome e lugar na lista da indústria, na categoria de configuração: o OWASP Top 10 sem jargão passa pelas dez.
O que fazer hoje
- Abra o código-fonte da sua página no ar e procure por key, token, secret e apikey. Veja também a aba de rede: muita chave viaja no pedido em vez de estar no HTML.
- Se achar uma com service, secret ou admin no nome, troque ela agora. Chave trocada transforma em lixo a cópia que alguém já possa ter.
- Ligue a regra de permissão em toda tabela que guarda alguma coisa sobre uma pessoa, e confira abrindo o app deslogado.
- Peça pra ferramenta onde você construiu mover aquela chamada pro lado do servidor, e diga com todas as letras: a chave não pode chegar no navegador.
Nada disso exige que você vire uma pessoa de segurança. Exige saber que a página é pública, que a chave é parte da página, e que a regra é uma coisa separada que você precisa ligar. E se alguém já te entregou uma lista de achados e nada virou conserto, um relatório com 147 achados não conserta nada.
Será que isso está acontecendo no seu app?
O SecureDragon olha o seu app por fora, acha o que ficou aberto, explica em português claro e te entrega o texto que conserta. O primeiro teste é de graça, sem cartão.
Testar meu app de graça