Como evitar publicar chaves de API e segredos em sites criados por IA

Uma landing page estática não tem um lugar secreto onde esconder uma credencial. Tudo o que chega ao navegador — HTML, CSS, JavaScript, mapas de código, arquivos de configuração e respostas de rede — pode ser inspecionado por quem abre a página.

Isso continua verdadeiro quando um agente de IA cria o site. O agente acelera a geração de arquivos, mas também pode copiar uma chave de um exemplo, transformar uma variável de ambiente em código do cliente ou incluir no pacote algo que deveria ficar apenas no ambiente de desenvolvimento.

Evitar publicar chaves de API exige revisar a saída real, não apenas o prompt ou o repositório. O processo seguro passa por fonte, build, pacote final e URL publicada.

Comece pela regra que não tem exceção

Se um valor concede acesso que uma pessoa anônima não deveria ter, ele não pode ser enviado ao navegador.

Isso inclui:

• chaves privadas de API;
• tokens de acesso;
• credenciais de banco de dados;
• segredos usados para assinar sessões ou webhooks;
• chaves privadas de serviços em nuvem;
• senhas, cookies ou cabeçalhos copiados de uma sessão;
• arquivos .env com valores reais;
• URLs internas que carregam credenciais na própria string.

Prefixos como PUBLIC_, NEXT_PUBLIC_ e VITE_ não protegem um valor. Ao contrário: normalmente sinalizam que ele pode ser incorporado ao código entregue ao navegador. Use esses mecanismos apenas para configurações que já são públicas, como uma URL de API sem credencial.

Diferencie identificador público de segredo

Nem toda sequência parecida com chave é confidencial. Alguns serviços fornecem identificadores públicos para Analytics, mapas, widgets ou pagamentos. Esses valores podem aparecer no frontend porque foram desenhados para isso.

A decisão não deve ser tomada pela aparência do valor. Registre para cada integração:

Quando a resposta não estiver clara, trate o valor como segredo até confirmar o contrato do serviço.

Entenda como o vazamento entra no site

Um segredo pode aparecer no pacote final por caminhos menos óbvios do que uma constante chamada API_KEY.

Código gerado com valor de exemplo

O agente recebe uma credencial no contexto e a escreve diretamente em fetch(), em um arquivo de configuração ou em um snippet de integração. O site funciona no primeiro teste, mas a credencial passa a fazer parte do JavaScript público.

Variável de ambiente exposta no build

O projeto usa uma variável durante a compilação. A ferramenta substitui a referência pelo valor real e produz um bundle que já contém o segredo. Remover o .env do .zip não corrige o bundle.

Arquivo extra incluído no pacote

Um comando comprime a raiz do projeto e leva junto .env, logs, backups, fixtures, arquivos de credenciais ou uma pasta de configuração local.

Source map ou comentário

O bundle principal parece limpo, mas um arquivo .map, um comentário ou um exemplo antigo preserva código-fonte, nomes internos e valores que não deveriam ser públicos.

Resposta de API no navegador

O segredo não está nos arquivos, mas o frontend chama um endpoint que devolve dados demais. A aba Network do navegador revela o conteúdo mesmo que a interface esconda parte dele.

A orientação da OWASP para revisão de vazamento em páginas recomenda inspecionar HTML, JavaScript e source maps em busca de informações sensíveis. É exatamente o que precisa ser feito antes e depois do deploy.

Mantenha operações privilegiadas fora da landing page

Quando uma ação depende de segredo, coloque-a atrás de um backend controlado. O navegador envia somente os dados necessários; o servidor valida a solicitação, aplica limites e usa a credencial no ambiente privado.

Esse desenho é necessário para operações como:

• gravar diretamente em banco de dados;
• enviar e-mail com credencial privada;
• criar cobranças privilegiadas;
• acessar CRM com token administrativo;
• assinar uploads;
• consumir APIs pagas sem autenticação do usuário.

O backend não transforma automaticamente a operação em segura. Ele ainda precisa validar entrada, autenticar quando necessário, limitar abuso e devolver apenas os dados que o frontend pode conhecer. Mas cria a fronteira correta: o segredo não viaja no pacote estático.

Se a landing page usa um formulário, teste também o fluxo completo de destino e confirmação. O checklist de QA para landing pages ajuda a separar bloqueios de publicação de ajustes menores.

Dê ao agente um contrato explícito

Não espere que o agente adivinhe quais valores são públicos. Inclua regras de segurança no pedido:

Prepare a versão publicável desta landing page.

Antes de gerar o pacote:
- não copie chaves, tokens, cookies, senhas ou valores de .env para HTML ou JavaScript;
- não inclua .env, logs, backups, source maps ou arquivos de credenciais;
- liste todas as integrações externas encontradas;
- diferencie identificadores públicos de segredos com base na documentação do fornecedor;
- interrompa se uma operação do frontend exigir credencial privada;
- examine a pasta final, não apenas o código-fonte;
- devolva os arquivos incluídos, os checks executados e qualquer risco pendente.

O pedido melhora o comportamento do agente, mas não substitui a revisão. A evidência precisa existir no pacote.

Revise em quatro camadas

1. Fonte

Procure valores sensíveis e referências a arquivos locais no código, na configuração e nos exemplos. Revise também o diff: ele mostra o que entrou agora sem misturar todo o histórico.

Não dependa apenas de uma lista de palavras. Um token pode ter nome genérico, e uma string longa pode ser apenas um hash público. Combine busca automatizada com contexto.

2. Saída do build

Faça a mesma revisão na pasta que será publicada. Bundlers transformam, concatenam e copiam arquivos; por isso, uma fonte limpa não garante uma saída limpa.

Confirme também se source maps são necessários em produção. Quando não forem, exclua-os do pacote. Quando forem necessários para observabilidade, avalie um fluxo em que não fiquem públicos.

3. Pacote

Liste o conteúdo do .zip ou diretório final. Um pacote mínimo para site estático deve conter somente o que a página precisa para funcionar.

O contrato de publicação do Site no Ar trabalha com esses arquivos: index.html vira a home, outros HTMLs podem virar rotas e os demais itens são servidos como assets. Se um arquivo sensível entra no upload, trate-o como potencialmente público.

4. URL publicada

Abra a página, use as ferramentas do navegador e confira:

• código-fonte e arquivos JavaScript carregados;
• respostas na aba Network;
• arquivos .map e caminhos previsíveis;
• comentários, mensagens de erro e objetos globais;
• integrações que recebem ou devolvem dados;
• ausência de arquivos que não pertencem ao site.

Verificar a URL é parte do deploy. O fluxo de publicação automática com agente só termina quando a versão pública foi conferida.

Se encontrou um segredo, remover não basta

Considere a credencial comprometida assim que ela apareceu em um arquivo publicado, commit compartilhado, log externo ou mensagem acessível a terceiros.

O plano de resposta deve:

1. revogar ou rotacionar a credencial;
2. interromper o uso da versão exposta;
3. remover o valor da fonte e da saída compilada;
4. republicar uma Version limpa;
5. verificar novamente a URL;
6. revisar logs e uso da credencial conforme o serviço permitir;
7. registrar como o valor entrou no fluxo para impedir repetição.

Substituir o arquivo sem rotacionar deixa a credencial antiga válida para quem já a copiou.

Publique uma Version verificável

No Site no Ar, peça a publicação a um agente conectado por MCP e preserve a mesma disciplina:

• caminhos sob public/ explícitos;
• inventário dos arquivos;
• Site e slug aprovados;
• nenhum segredo nos arquivos;
• URL final aberta e testada;
• pendências registradas no handoff.

As instruções de configuração do agente mostram como conectar o MCP. A conexão autoriza o fluxo de publicação; ela não transforma credenciais de frontend em segredos nem substitui os checks.

Checklist antes de colocar no ar

• Identificadores públicos foram confirmados na documentação oficial.
• Operações privilegiadas passam por um backend controlado.
• Nenhum .env, log, backup ou arquivo de credencial está no pacote.
• Fonte e saída de build foram examinadas separadamente.
• Source maps públicos foram removidos ou aceitos conscientemente.
• O conteúdo final do upload foi listado.
• Integrações externas e dados enviados foram inventariados.
• A URL publicada foi inspecionada no navegador.
• Existe um plano de rotação para qualquer credencial exposta.

O objetivo não é ensinar o agente a esconder melhor uma chave. É construir um fluxo em que o segredo nunca precise entrar no site público.