Como configurar variáveis de ambiente seguras (.env) para não expor senhas no código

Como configurar variáveis de ambiente seguras (.env) para não expor senhas no código

Oi, eu sou a Sensei da GeHost 🥋 Hoje vou te ensinar algo que separa um site amador de um site profissional: nunca, jamais, deixar senha, chave de API ou dado sensível escrito direto no código. A solução pra isso tem nome — variáveis de ambiente, guardadas num arquivinho chamado .env. Vem comigo que é mais simples do que parece.

Por que isso importa?

Se você escreve a senha do banco de dados, a chave do gateway de pagamento ou o token de um serviço direto dentro de um arquivo .php, .js ou .env exposto, qualquer pessoa que tiver acesso ao código (ou que consiga visualizar aquele arquivo pelo navegador, por erro de configuração) vê tudo isso. Se esse código for parar num repositório público (GitHub, por exemplo), pior ainda: a senha fica exposta pro mundo inteiro, para sempre.

Dica da Sensei: pense no .env como o cofre da sua casa — ele fica dentro da casa (seu servidor), mas nunca sai carregado no bolso pra qualquer lugar (código público, e-mail, print de tela).

O que é o arquivo .env?

É um arquivo de texto simples, geralmente na raiz do seu projeto, onde você guarda as informações sensíveis em formato CHAVE=valor, uma por linha. Exemplo (fictício, só pra ilustrar o formato):

DB_HOST=localhost
DB_USER=meu_usuario
DB_PASS=minha_senha_forte
API_KEY=chave_do_servico_de_pagamento

O código da sua aplicação lê essas variáveis em tempo de execução — em vez de ter a senha "escrita a fogo" no meio do código, ele pergunta "qual é o valor de DB_PASS?" e o sistema responde com o que está no .env.

Passo a passo para configurar

1. Crie o arquivo .env na raiz do seu projeto (fora da pasta pública, se possível — falamos disso já já).
2. Mova para lá tudo que for sensível: senha de banco de dados, chaves de API, tokens de e-mail, credenciais de gateway de pagamento etc.
3. Ajuste o código para ler essas informações do .env em vez de ter o valor "fixo" (hardcoded) no meio do script. A maioria das linguagens/frameworks modernos (PHP com Composer, Node.js, Python) tem uma biblioteca simples pra isso — se você tem um desenvolvedor cuidando do seu site, é só pedir pra ele aplicar esse padrão.
4. Nunca envie o .env para o controle de versão (Git/GitHub). Se o seu projeto usa Git, adicione a linha .env no arquivo .gitignore — assim ele nunca é enviado junto com o código.
5. Use um arquivo de exemplo chamado .env.example, com as mesmas chaves mas SEM os valores reais (ex.: DB_PASS=), pra qualquer pessoa da equipe saber quais variáveis existem sem ver a senha de verdade.

Protegendo o .env no servidor (hospedagem cPanel)

Só tirar a senha do código não basta — também é preciso garantir que ninguém consiga acessar o arquivo .env digitando a URL dele no navegador. No seu painel cPanel, você pode conferir e organizar seus arquivos pelo Gerenciador de Arquivos:

• Sempre que possível, guarde o .env fora da pasta public_html (que é a pasta pública do site) — assim ele fica fora do alcance de quem navega direto pelo domínio.
• Se o seu sistema exigir que o .env fique dentro de public_html, peça pro seu desenvolvedor adicionar uma regra no arquivo .htaccess daquela pasta bloqueando o acesso direto a arquivos .env pelo navegador.
• Depois de configurar, teste digitando o endereço do seu .env no navegador (ex.: seusite.com.br/.env) — o esperado é dar erro de acesso negado ou página não encontrada. Se o conteúdo aparecer na tela, é sinal de que precisa ajustar a proteção urgente.

Boas práticas extras

• Senhas fortes e únicas: nunca reaproveite a mesma senha em vários serviços.
• Ambientes diferentes, arquivos diferentes: se você tem um ambiente de testes e um de produção, use um .env para cada um, com credenciais diferentes.
• Troque credenciais expostas: se em algum momento uma senha ou chave chegou a vazar (foi parar num repositório público, por exemplo), o certo é trocá-la imediatamente — só remover do código não invalida o valor antigo.
• Backups também merecem cuidado: ao fazer backup do seu projeto, lembre que o .env estará junto — guarde esses backups em local seguro e não compartilhado.

Dica da Sensei: se você não mexe direto com código e tem um desenvolvedor cuidando do seu site, basta mandar esse guia pra ele — é literalmente o padrão que qualquer profissional de tecnologia já conhece e vai aplicar rapidinho.

Ficou com dúvida em algum passo ou quer ajuda pra revisar a segurança do seu site? É só chamar a gente pelo painel.gehost.com.br — a equipe da GeHost está por aqui pra te ajudar. 🌱