O .env é extremamente prático e quase todo framework moderno o usa. Mas coloque-o no lugar errado uma única vez e todos os segredos nele podem ser lidos por qualquer pessoa. Veja o que ele é e como protegê-lo, do zero.
Um pouco mais de detalhe
Os aplicativos têm "valores que mudam por ambiente" e "valores que você não quer que ninguém veja": a senha do banco, chaves de API externas, a chave que criptografa as sessões. Codifique-os direto no fonte e os segredos vazam no instante em que você compartilha o código.
Então você os reúne em um único arquivo .env e os lê como "variáveis de ambiente" a partir do código. Next.js, Laravel, Rails e muitos frameworks funcionam assim.
O conteúdo é texto puro, um NOME=valor por linha (os valores abaixo são apenas exemplos).
APP_ENV=production
DB_HOST=127.0.0.1
DB_PASSWORD=your-db-password-here
PAYMENT_API_KEY=your-payment-api-key-hereManter a configuração fora do código foi popularizado pelo guia de design de aplicativos web "The Twelve-Factor App". O teste que ele propõe para saber se a configuração está bem separada é: o código poderia virar open source a qualquer momento sem comprometer nenhuma credencial? O .env é um recipiente conveniente para essa ideia durante o desenvolvimento.
Como ele se diferencia de coisas parecidas
Estas são as coisas mais confundidas com o .env. Só algumas delas são um lugar seguro para segredos.
| Nome | O que é | Serve para segredos? |
|---|---|---|
| Variáveis de ambiente | Valores que o SO ou o contêiner passa para um processo em execução | Sim (o padrão em produção) |
.env | Variáveis de ambiente reunidas em um arquivo | Sim, mas nunca em diretório público nem no Git |
.env.example | Um exemplo que lista os nomes com valores vazios | Não (ele é feito para ser commitado) |
NEXT_PUBLIC_* / VITE_* | Variáveis embutidas no JavaScript do navegador | Não (qualquer pessoa pode lê-las) |
| Gerenciador de segredos | Um serviço de nuvem para guardar valores secretos | Sim; gerenciado com permissões e logs de auditoria |
A quarta linha é a que passa despercebida. O Next.js embute os valores das variáveis que começam com NEXT_PUBLIC_, e o Vite os das que começam com VITE_, no JavaScript enviado ao navegador no momento do build. Mesmo estando no .env, uma variável com um desses prefixos se torna pública.
Por que ele é o "arquivo mais perigoso"
Como várias chaves ficam em um único arquivo, uma única exposição espalha o dano rápido. Listar "o que cada valor vazado destrava" deixa a severidade clara.
| Valor vazado | O que acontece |
|---|---|
| Credenciais do banco | ler / alterar / apagar dados |
| Chaves de API externa | uso por personificação, cobrança fraudulenta |
Chave de criptografia (por exemplo, APP_KEY do Laravel, chaves de assinatura) | falsificação de sessão, login por personificação |
| Segredos OAuth | tomada de controle de apps vinculados |
De fato, expor o .env é um incidente clássico. → O .env exposto ao mundo inteiro
Casos reais: arquivos .env expostos sendo visados
- Uma operação de extorsão em grande escala (2024): a equipe de pesquisa de uma empresa de segurança relatou uma atividade que visou 110.000 domínios, coletou arquivos
.envexpostos em servidores web, usou as credenciais de nuvem contidas neles para levar dados e exigiu resgate. Foram coletadas mais de 90.000 variáveis, cerca de 7.000 delas de serviços de nuvem e cerca de 1.500 de contas de redes sociais. A causa não foi uma vulnerabilidade do provedor de nuvem, e sim a configuração incorreta das organizações que expuseram seus.env - Vercel (abril de 2026): um acesso não autorizado a sistemas internos levou à leitura das variáveis de ambiente de alguns clientes — as guardadas na categoria cujos valores podem ser exibidos novamente → análise completa (em inglês)
- Repositórios públicos (um estudo de 2026): mais de 540.000 credenciais publicadas no GitHub ainda estavam válidas na época do estudo. Apagar o arquivo ou o histórico não adianta se a credencial não for revogada → análise completa (em inglês)
O primeiro caso mostra que arquivos .env expostos não são achados por pessoas navegando — eles são coletados de forma automática e em grande escala. Não presuma que um site pequeno não será encontrado.
O vazamento típico = um erro de posicionamento
A maior causa é "colocar o aplicativo inteiro no diretório público (docroot)". Onde só public/ deveria ser servido, expor o diretório pai torna o .env alcançável também.
✗ Perigoso (app na raiz pública)
public_html/ ├─ .env ← legível! ├─ app/ └─ public/
✓ Seguro (app fora, só public servido)
app-root/ ├─ .env ← inalcançável ├─ app/ └─ public_html/ → public/
Além do posicionamento, ele também vaza por estes caminhos:
- Fazer commit dele no Git (público na hora num repositório público; visível para todos com acesso num privado)
- Deixar backups como
.env.bakou.env.oldno diretório público - Distribuir uma imagem de contêiner ou um zip com o
.envainda dentro - Colocar segredos em variáveis
NEXT_PUBLIC_/VITE_, como descrito acima
Como protegê-lo
Não o coloque em um diretório público
Mantenha o app fora do docroot; sirva apenas public/. Passos concretos para hospedagem compartilhada: este guia.
Não o commit no git
Adicione .env* ao .gitignore e compartilhe apenas um .env.example com valores vazios.
Gire tudo se ele vazar
Não apenas a chave confirmada — substitua todas as chaves que estavam no .env. Aja como se todas tivessem sido vistas.
Faça autoverificação regularmente
Crie o hábito de verificar que /.env não pode ser aberto no seu próprio site.
Como verificar o seu site e o seu repositório
Autoverificação (apenas contra domínios que você possui)
# Um 200 com corpo significa que está exposto. 403/404 está ok por enquanto.
curl -sI https://yourdomain/.env | head -1
curl -sI https://yourdomain/.git/config | head -1Verificar isso a cada deploy detecta erros de posicionamento cedo.
Verifique tanto o lado de fora do site quanto o interior do repositório.
- Para um site cuja propriedade você verificou, a auditoria de segurança do site checa
/.env,/.env.local,/.env.bake caminhos parecidos de uma só vez - No repositório, rode
git log --all --oneline -- .envpara ver se ele já foi commitado alguma vez. Se aparecer algo, revogue as chaves que ele continha - Cole configurações ou código no scanner de vazamento de segredos para achar chaves de API ou chaves privadas escritas direto no código (ele roda no seu navegador)
- Revise a lista de variáveis
NEXT_PUBLIC_/VITE_para garantir que nenhum segredo vá parar no JavaScript gerado pelo build
A visão deste site: decida juntos onde o .env fica e como revogar as chaves dele
A maioria dos incidentes com .env começa com um único arquivo no lugar errado. O que faz o dano se espalhar depois é não ter um procedimento definido para trocar as chaves.
Neste site recomendamos que, se você usa .env, além de mantê-lo fora do diretório público e do Git, deixe anotado com antecedência como revogar e reemitir cada chave que ele contém. Em produção, migrar para um gerenciador de segredos na nuvem ou para variáveis de ambiente cujos valores não podem ser exibidos novamente reduz ainda mais os caminhos de vazamento.
Fontes (primárias)
- The Twelve-Factor App, "III. Config" (em inglês) — 12factor.net (guardar a configuração em variáveis de ambiente; o teste do open source)
- Documentação do Next.js, "Environment Variables" (em inglês) — nextjs.org (
NEXT_PUBLIC_é embutido no JavaScript no build; não commitar arquivos .env) - Documentação do Vite, "Env Variables and Modes" (em inglês) — vite.dev (variáveis
VITE_ficam expostas ao código do cliente) - Unit 42 (Palo Alto Networks), "Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments" (15 de agosto de 2024) (em inglês) — unit42.paloaltonetworks.com
Leia a seguir
- Incidentes: O .env do Laravel exposto ao mundo · Exposição de variáveis de ambiente na Vercel (em inglês)
- Defesa: Mantendo o .env fora da web pública em hospedagem compartilhada · Auditando arquivos secretos em diretórios públicos · Barrando segredos antes do commit
- Fundamentos: O que é perigoso no .env e nas chaves de API