Posso colocar minha chave de API no código do meu site?
Uma chave secreta, não. Tudo o que o navegador executa — HTML, JavaScript, CSS — é enviado a cada visitante, então uma chave secreta colada numa página é pública no instante em que você publica, e minificar ou dividir em três pedaços não muda nada. Algumas chaves devem ficar ali: os fornecedores as chamam de publicáveis ou de cliente e as limitam para que ser pública seja seguro. Se uma chave secreta já está numa página no ar, gire-a no fornecedor antes de mexer na página, porque tirar a página do ar não desfaz o que já foi servido.
Por que uma página não consegue guardar segredo
O navegador precisa receber tudo o que executa. Isso não é uma falha de uma hospedagem ou de um framework específico, é o que significa servir uma página: a máquina do visitante não roda o seu código sem receber o seu código. Por isso as ferramentas de desenvolvedor do próprio navegador bastam para ler o que estiver lá, sem conhecimento técnico e sem instalar nada. Minificar, codificar em base64 ou montar a chave a partir de fragmentos concatenados sobrevivem exatamente o tempo que alguém leva para olhar o valor já montado, que a aba de rede mostra de todo jeito, dentro da requisição que sai.
Então a distinção que importa não é escondido contra visível. É entre dois tipos de credencial, e o fornecedor nomeia as duas para você. Uma chave publicável ou de cliente é feita para viver numa página: a chave publicável de um meio de pagamento, um identificador de medição de analytics, uma chave de mapas restrita ao seu domínio. Elas são públicas por projeto e cercadas do lado do fornecedor, e é por isso que colocá-las no código do site é correto, não arriscado. Uma chave secreta é outra coisa completamente: em geral carrega toda a autoridade da sua conta, então pode cobrar cartões, ler registros de clientes, enviar e-mail no seu nome ou queimar seu orçamento de API. Entregar isso a qualquer pessoa que abra a página é o erro de verdade, e "ninguém conhece esse endereço ainda" não é defesa, porque há scanners varrendo sites recém-publicados e repositórios públicos continuamente à procura exatamente disso.
Se já está no ar, gire antes de arrumar
O impulso é apagar a linha e publicar de novo. Faça a outra coisa primeiro. Tirar do ar não recupera o que já foi servido: a versão antiga pode ficar no cache de uma CDN, no cache de um buscador, num serviço de arquivamento ou no navegador de um visitante, e se a página vive num repositório a chave permanece no histórico de commits, onde remover a linha num commit posterior deixa o anterior perfeitamente legível. O único passo que realmente encerra a exposição é invalidar a credencial no fornecedor, porque o fornecedor é o único lugar onde a chave precisa ser conferida.
- Revogue ou renove a chave antiga para que ela pare de funcionar — criar uma segunda chave ao lado dela não muda nada.
- Emita uma substituta e guarde-a onde a página não consiga ler, o que na prática significa configuração do lado do servidor.
- Leia o registro de uso ou de auditoria do fornecedor em toda a janela de exposição e procure chamadas que você não fez.
- Se a chave podia movimentar dinheiro ou alcançar registros de clientes, verifique cobranças que você não reconhece e cumpra as obrigações do fornecedor e as suas sobre avisar quem foi afetado.
- Só então arrume a página — e confira o conserto baixando a página publicada e procurando o valor antigo na resposta, em vez de confiar no editor.
Onde a chave fica no lugar disso, e o que encontramos em páginas no ar
O padrão que funciona é a página nunca guardar o segredo. A página chama algo que você controla, essa coisa guarda a chave e faz a chamada de saída, e o navegador do visitante só conversa com você. Muitas vezes você não precisa hospedar isso: o widget hospedado de um fornecedor ou um serviço de backend gerenciado fazem o papel de servidor aqui. Se você precisa de mais do que isso é outra pergunta, e meu site precisa de um backend mostra onde a linha realmente fica.
Operar nossa própria hospedagem nos ensinou algo contraintuitivo sobre isso. O AgentCeres — o AI Growth Officer em agentceres.com — hospeda as páginas que seus agentes constroem para os clientes, e cada uma delas é servida com uma política de segurança de conteúdo que impede a página de fazer qualquer requisição de rede. Uma chave embutida numa página assim não pode nem ser usada por ela: o código roda, calcula e navega, e não tem para onde mandar nada. Essa contenção protege o visitante da página, e não faz absolutamente nada para esconder a chave do visitante — que é a metade que as pessoas presumem ganhar de graça.
Em 2026-09-17 revisamos as páginas que os clientes tinham publicado e encontramos uma cujo JavaScript atribuía a uma variável a chave secreta real de um meio de pagamento, com o número de CPF de um cliente escrito à mão numa função de consulta mais abaixo no mesmo arquivo. As duas coisas foram confirmadas baixando a página no ar, não deduzidas. Nada de exótico havia acontecido: o dono colou a chave num chat ao pedir um recurso que precisava dela, e ela foi escrita na página. A regra que saiu dali é a que vale levar — nunca cole um segredo real num chat com algo que escreve a sua página, assistente de código incluído, porque o natural para ele é usar a chave onde o código está.
A mesma revisão encontrou o vazamento no sentido contrário, o que vale saber porque quase ninguém verifica. Páginas geradas incluem formulários de login e de cadastro quando alguém pede uma área de membros, mesmo onde não existe servidor atrás para autenticar ninguém, e todo formulário dessa página acaba ligado a um coletor de formulários — então um visitante que digitava uma senha ali a tinha armazenada e repassada em texto puro. Em dois casos de setembro de 2026 isso incluiu o e-mail e a senha reais de um terceiro, chegando na caixa de entrada do dono com a aparência de um contato comum. Agora reconhecemos nomes de campo com cara de credencial e removemos esses valores antes que algo seja armazenado, enviado ou exibido, e páginas recém-publicadas já deixam esse campo sem envio possível. A lição geral vale independentemente de quem construiu a página: ela pode vazar nas duas direções, suas chaves para fora e as senhas dos seus visitantes para dentro.
Perguntas frequentes
- É seguro colocar uma chave de API publicável ou pública no meu site?
- Sim — é para isso que elas existem, e um recurso de front-end que precisa de uma não tem outra opção. Duas coisas a tornam segura, e não apenas permitida: o fornecedor limita o que aquela classe de chave pode fazer, e você aplica a restrição que o fornecedor oferecer, normalmente uma lista de domínios para os quais a chave vai responder. Sem a restrição, uma chave pública continua não sendo perigosa para a sua conta, mas pode ser usada do site de outra pessoa e cobrada de você.
- Consigo manter a chave privada colocando-a numa variável de ambiente?
- Só se o código que a lê rodar num servidor. Esse é o mal-entendido mais comum, porque ferramentas de build de front-end embutem de propósito as variáveis de ambiente que levam o prefixo público — NEXT_PUBLIC_, VITE_, REACT_APP_ e equivalentes — dentro do bundle em tempo de build. A variável é privada nas configurações do projeto e o valor fica assado no JavaScript que você serve, então termina na página exatamente como se você a tivesse digitado ali.
- Minha chave foi exposta mas o fornecedor não mostra uso inesperado. Ainda preciso girar?
- Sim. Um log quieto diz que ninguém a usou ainda, não que ninguém a tenha, e scanners automáticos rotineiramente coletam chaves muito antes de fazerem algo com elas. Girar custa minutos agora e a alternativa é um risco aberto que você não fecha vigiando. Trate um log limpo como boa notícia sobre o passado, não como uma decisão sobre o futuro.
Quer que a gente faça isso por você?
A AgentCeres é uma equipe de marketing com IA gerenciada: especialistas redigem o trabalho e você aprova o que vai ao ar. 14 dias de teste grátis, a partir de R$ 99/mês.