Variáveis de ambiente e segredos: o .env não é cofre

Senhas de banco, chaves de APIs e tokens de serviços precisam existir em algum lugar para o sistema funcionar. O arquivo .env virou o lugar padrão — e também uma das maiores fontes de vazamento.

Os vazamentos mais comuns

1. 1.`.env` commitado no repositório, às vezes público.
2. 2.Variáveis "do frontend" contendo segredos, embutidas no código enviado ao navegador (Chave de API no frontend: o vazamento mais comum que encontramos).
3. 3.Segredos em logs de erro ou de build (Logs sem dados sensíveis: o vazamento que ninguém percebe).
4. 4.Prints e mensagens compartilhados com a configuração aberta.
5. 5.O mesmo segredo em desenvolvimento e produção.

Boas práticas

• `.env` sempre no `.gitignore`, com um .env.example sem valores reais.
• Segredos de produção no painel da plataforma de hospedagem ou num gerenciador de segredos — nunca em arquivo no servidor acessível a todos.
• Separe por ambiente: chaves de teste para desenvolvimento.
• Permissões mínimas: cada chave com o menor acesso possível.
• Rotação: troque periodicamente e sempre que alguém com acesso sair.
• Valide na inicialização: o sistema não deve subir se faltar uma variável obrigatória.

const Env = z.object({ DATABASE_URL: z.string().url(), JWT_SECRET: z.string().min(32) })
export const env = Env.parse(process.env)

Se vazou

Revogue, gere uma nova, verifique o uso e limpe o histórico do repositório.

Chaves fortes também são essenciais para assinar tokens (JWT: as armadilhas que deixam sua API aberta).

A We Codex faz essa revisão em Segurança Anti-Hacker. Fale com a gente.