Como Manter as Chaves de API Seguras no Seu App

Para manter as chaves de API seguras, guarde-as como segredos ou variáveis de ambiente na sua hospedagem, use-as apenas em código do servidor e nunca as cole em chats, arquivos de código, capturas de tela ou em um repositório Git. Dê a cada chave a menor permissão de que ela precisa, defina limites de gasto no provedor e, se uma chave vazar, troque-a — crie uma nova e apague a antiga — em vez de apenas escondê-la do lugar onde apareceu.

Uma chave de API é a senha de um serviço. Sua chave da OpenAI permite que alguém gaste o seu dinheiro com IA; sua chave secreta da Stripe permite emitir reembolsos; sua chave do provedor de e-mail permite enviar mensagens em seu nome. Os construtores de apps com IA são bons em conectar essas chaves, mas nem sempre são cuidadosos com o lugar onde elas acabam. Este guia mostra como mantê-las seguras e como verificar.

Chaves públicas x chaves secretas

Nem toda chave é secreta. Saber a diferença evita que você entre em pânico com a chave errada e ignore a certa.

Se não tiver certeza de que tipo é uma chave, consulte a documentação do provedor. Na dúvida, trate-a como secreta.

Passo 1: Guarde as chaves como segredos, não no código

As chaves pertencem às variáveis de ambiente ou às configurações de segredos da sua hospedagem. O seu código as lê pelo nome em tempo de execução (por exemplo process.env.OPENAI_API_KEY), então o valor nunca aparece nos seus arquivos. Para entender o básico, veja o que são variáveis de ambiente e segredos.

Mova cada chave de API do código para variáveis de ambiente. Liste cada chave que você encontrou, em qual arquivo estava e o nome da variável que você usou. Não mostre os valores.

Depois, confira se não sobrou nada:

Pesquise em todo o projeto, incluindo arquivos de configuração e qualquer arquivo .env, qualquer coisa que pareça uma chave de API ou senha. Informe o arquivo e a linha, não o valor.

Passo 2: Use chaves secretas somente no servidor

Esta é a regra mais importante. Tudo o que o navegador recebe, um visitante pode ler — o código-fonte da página e os arquivos JavaScript estão todos visíveis nas ferramentas de desenvolvedor.

Por isso, se o app precisa chamar a OpenAI, o navegador deve chamar o seu servidor, e o seu servidor chama a OpenAI com a chave. A chave nunca sai do servidor.

O recurso de chat chama a OpenAI diretamente do navegador. Mova essa chamada para uma rota de API no servidor que lê OPENAI_API_KEY do ambiente. O navegador deve chamar apenas a nossa rota. Exija login para acessar a rota.

Fique atento a uma armadilha comum em frameworks de frontend: as variáveis com prefixo público — VITE_ no Vite, NEXT_PUBLIC_ no Next.js — são incorporadas ao código do navegador de propósito. Uma chave secreta com um desses prefixos fica exposta, mesmo estando "em uma variável de ambiente".

Passo 3: Teste se nada vaza

Não confie que funcionou — confira o site no ar:

1. Abra o app publicado em um navegador.
2. Abra as ferramentas de desenvolvedor e a aba Sources ou Network.
3. Pesquise em todos os arquivos pelos primeiros caracteres de cada chave secreta (por exemplo sk_ ou sk-).
4. Veja as requisições de rede que o app faz. Uma requisição indo direto do navegador para um provedor de IA pago é um sinal de alerta.

Se encontrar uma chave secreta, mova-a para o servidor (passo 2) e troque-a (passo 6), porque ela já estava pública.

Passo 4: Restrinja o que cada chave pode fazer

Muitos provedores permitem limitar uma chave:

• Chaves restritas ou com escopo que só podem fazer o que o seu app precisa. A Stripe, por exemplo, oferece chaves restritas com permissões específicas.
• Restrições por domínio ou IP para chaves que precisam ser públicas, como as de mapas.
• Chaves separadas por app e por ambiente, para que um vazamento não exponha tudo e revogar uma não quebre as outras.
• Chaves de teste durante a construção, e chaves reais apenas no app publicado.

Passo 5: Coloque um teto nos danos

Até uma chave bem protegida pode ser mal usada pelo seu próprio app — alguém automatizando o seu recurso de IA milhares de vezes, por exemplo.

• Configure limites ou alertas de gasto em todos os provedores pagos.
• Exija login para qualquer recurso que custe dinheiro a cada uso.
• Adicione um limite de uso por usuário. Veja o que é limitação de taxa (rate limiting).

Adicione um limite de 30 requisições de IA por usuário por hora em /api/chat. Mostre uma mensagem clara quando o limite for atingido. Rejeite requisições de usuários que não estão logados.

Passo 6: Troque as chaves que vazaram

Se uma chave secreta aparecer em algum lugar onde não deveria — uma mensagem de chat, um commit, uma captura de tela, um chamado de suporte, código do navegador —, considere que ela está comprometida.

1. Crie uma nova chave no provedor.
2. Atualize o segredo nas configurações do seu app.
3. Refaça o deploy ou publique de novo para que o app no ar use a nova chave.
4. Apague a chave antiga no provedor.
5. Confira os registros de uso do provedor para atividades que você não reconhece.

Apagar a mensagem do chat ou o commit do Git não basta. O histórico do Git guarda versões antigas, e tudo o que foi público pode já ter sido copiado.

Erros comuns

• Colar uma chave no prompt. Ela fica no histórico do chat. Use um formulário de segredos.
• Um prefixo público em uma variável secreta. VITE_OPENAI_API_KEY envia a chave para todos os visitantes.
• Commitar um arquivo .env. Garanta que ele esteja no .gitignore antes do primeiro push.
• Uma chave para tudo. Use chaves separadas para teste e produção, e para cada app.
• Sem limite de gasto. Uma chave vazada ou abusada sem teto pode gerar uma conta grande antes de você perceber.
• Esconder em vez de trocar. Depois que uma chave foi exposta, só uma nova resolve.
• Chaves em capturas de tela. Recorte ou desfoque as páginas de configuração antes de compartilhá-las para pedir ajuda.

Checklist

• Cada chave está guardada como segredo ou variável de ambiente, não no código.
• Nenhum arquivo .env ou chave está commitado no Git.
• Chaves secretas são usadas somente em código do servidor.
• Nenhuma variável secreta usa um prefixo público como VITE_ ou NEXT_PUBLIC_.
• Pesquisei o JavaScript do site no ar pelo prefixo de cada chave e não encontrei nada.
• As chaves têm escopo ou restrições onde o provedor permite.
• Chaves de teste e de produção são separadas.
• Recursos pagos exigem login e têm limites por usuário.
• Todo provedor pago tem um teto ou alerta de gasto.
• Sei como trocar cada chave, e qualquer chave que já foi exposta foi trocada.

Mantendo as chaves seguras na Mythex

A Mythex mantém as chaves fora do seu código e do chat de duas formas:

• Cartão de pedido de segredos. Quando o agente precisa de uma chave, ele mostra um cartão no chat em que você digita o valor em campos de formulário, não na caixa de mensagem, e ele é guardado como segredo do projeto. Veja Segredos no chat.
• Configurações do projeto → Secrets, ou /secrets no chat, para adicionar ou alterar chaves você mesmo. Veja Variáveis de ambiente e segredos.

Depois de alterar um segredo de um app publicado, publique de novo para que o app no ar o use. Projetos exportados não incluem os segredos, então adicione-os de novo onde for rodar o código. Se uma chave aparecer no chat, troque-a no provedor.

Para o restante da revisão de segurança antes do lançamento, siga a lista de verificação de segurança para apps criados com IA. Se você está adicionando recursos de IA, como usar APIs de LLM explica chaves e custos com mais profundidade.

Perguntas