Inspetor .ENV — Ferramenta Online Gratuita

O Que o Inspetor .ENV Verifica?

O Inspetor .ENV analisa seu arquivo de variáveis de ambiente em três categorias de problemas: risco de exposição de secrets, problemas de formato e completude. Ele analisa cada linha, classifica variáveis por sensibilidade e ajuda você a gerar um arquivo template seguro para sua equipe.

Detecção de Padrões de Secrets

O inspetor marca variáveis cujos nomes correspondem a padrões comuns de credenciais sensíveis. Variáveis são classificadas como secrets quando sua chave contém qualquer um destes padrões:

• Credenciais de API: API_KEY, API_SECRET, API_TOKEN, ACCESS_KEY, ACCESS_TOKEN
• Autenticação: PASSWORD, PASSWD, PWD, AUTH, BEARER, OAUTH, SESSION_SECRET
• Criptografia: PRIVATE_KEY, SECRET, HMAC, SALT, SIGNING_KEY, ENCRYPTION_KEY
• Banco de dados: DATABASE_URL, DB_URL, MONGO_URI, POSTGRES_URL, MYSQL_URL, CONNECTION_STRING, DSN
• Infraestrutura: WEBHOOK_SECRET, CERTIFICATE, CREDENTIAL, REDIS_PASSWORD

Problemas Comuns de Formato .env

• Sinal de igual ausente: Toda variável deve seguir o padrão KEY=VALUE. Linhas sem = são inválidas.
• Nomes de chave inválidos: Chaves devem conter apenas letras maiúsculas, números e underscores. Chaves que começam com números ou contêm espaços são inválidas na maioria dos ambientes.
• Valores com espaços sem aspas: Valores que contêm espaços devem ser envolvidos em aspas: APP_NAME="My Application"
• Comentários inline: Alguns parsers não suportam comentários inline (PORT=3000 # web port). Coloque comentários em sua própria linha.
• Espaços à direita: Espaços em branco no final dos valores podem causar bugs sutis, especialmente com passwords e tokens.

Boas Práticas de Segurança .env

• Sempre adicione .env ao .gitignore: Execute echo ".env" >> .gitignore antes do seu primeiro commit. Uma vez que um secret está no histórico do git, ele deve ser considerado comprometido — a rotação é a única solução.
• Faça commit do .env.example: Documente quais variáveis são necessárias sem expor valores reais. Novos membros da equipe copiam este arquivo e preenchem seus próprios secrets.
• Use credenciais diferentes por ambiente: Produção, staging e desenvolvimento devem ter API keys e credenciais de banco de dados separadas. Nunca reutilize secrets de produção em desenvolvimento.
• Rotacione secrets regularmente: Trate secrets como passwords — rotacione periodicamente e imediatamente quando alguém com acesso sai da equipe.
• Use um gerenciador de secrets em produção: Para workloads de produção, prefira soluções dedicadas de gerenciamento de secrets como AWS Secrets Manager, HashiCorp Vault ou Doppler em vez de arquivos .env no disco.
• Nunca registre variáveis de ambiente em log: Evite imprimir process.env nos logs, especialmente em produção. Configure filtragem de logs para ocultar padrões sensíveis.

Segurança de Variáveis de Ambiente no Desenvolvimento Moderno

Variáveis de ambiente são a forma padrão de configurar aplicações sem codificar valores sensíveis. No entanto, gerenciá-las incorretamente é uma das causas mais comuns de violações de segurança. Entender o manuseio adequado de arquivos .env é crítico para toda equipe de desenvolvimento.

O Ciclo de Vida do Arquivo .env: Do Desenvolvimento à Produção

• Desenvolvimento: Use um arquivo .env com valores fictícios ou locais. Faça commit de um arquivo .env.example com todas as chaves necessárias (mas sem valores reais) para que novos membros da equipe saibam o que configurar.
• CI/CD: Nunca armazene segredos no seu repositório. Use o gerenciamento de segredos da sua plataforma CI (GitHub Actions Secrets, GitLab CI Variables, ou CircleCI Contexts) para injetar variáveis de ambiente no momento do build.
• Staging/Produção: Use um gerenciador de segredos dedicado como AWS Secrets Manager, HashiCorp Vault, Google Secret Manager ou Doppler. Estes fornecem logs de auditoria, rotação automática e controle de acesso.

Erros Comuns de Segurança em .env

• Commitar .env no Git: Mesmo se você deletar o arquivo depois, ele permanece no histórico do Git para sempre. Se isso acontecer, rotacione imediatamente todos os segredos expostos e use git filter-branch ou BFG Repo-Cleaner para limpar o arquivo do histórico.
• Logar Variáveis de Ambiente: Nunca logue o ambiente completo (console.log(process.env) ou print(os.environ)). Isso despeja todos os segredos no seu agregador de logs onde podem ser acessíveis a membros não autorizados da equipe.
• Compartilhar via Chat/Email: Nunca compartilhe segredos através do Slack, email ou qualquer plataforma de mensagens. Use a funcionalidade de compartilhamento do seu gerenciador de segredos, ou ferramentas de compartilhamento de segredos únicos como Doppler ou compartilhamento seguro do 1Password.
• Usar Segredos em Código Frontend: Variáveis de ambiente com prefixo NEXT_PUBLIC_, VITE_, ou REACT_APP_ são incorporadas no bundle do lado do cliente e visíveis para qualquer pessoa. Nunca coloque chaves de API, credenciais de banco de dados ou segredos de autenticação em variáveis de ambiente do frontend.

Detecção e Prevenção de Segredos

Automatize a detecção de segredos no seu fluxo de trabalho de desenvolvimento para capturar vazamentos antes que cheguem à produção. Ferramentas como git-secrets, truffleHog e detect-secrets podem escanear commits em busca de padrões que correspondam a chaves de API, senhas e tokens. O GitHub também fornece escaneamento de segredos integrado para repositórios públicos que alerta quando formatos de segredos conhecidos são detectados no seu código.

Perguntas Frequentes sobre Arquivos .env

É seguro colar meu arquivo .env nesta ferramenta?

Sim — esta ferramenta roda inteiramente no seu navegador. Nenhum dado é transmitido para nenhum servidor. Você pode verificar isso abrindo DevTools do seu navegador na aba Network enquanto usa a ferramenta. Você verá zero requisições de saída. A análise acontece localmente em JavaScript e desaparece quando você fecha a aba.

O que é um arquivo .env e como ele funciona?

Um arquivo .env (dotenv) é um arquivo de texto simples que armazena variáveis de ambiente para sua aplicação. As variáveis seguem o formato KEY=VALUE, uma por linha. Bibliotecas como dotenv (Node.js), python-decouple (Python) ou godotenv (Go) carregam esses arquivos na inicialização, tornando as variáveis disponíveis como variáveis de ambiente no seu processo. Isso separa configuração do código — a mesma base de código roda em desenvolvimento, staging e produção com diferentes arquivos .env.

Qual é a diferença entre .env, .env.local e .env.production?

Muitos frameworks (Next.js, Vite, Create React App) suportam múltiplas variantes de arquivo .env com diferentes prioridades de carregamento. .env é o padrão carregado em todos os ambientes. .env.local sobrescreve o .env e é ignorado pelo git. .env.production e .env.development são específicos por ambiente. .env.local sempre tem prioridade sobre arquivos específicos de ambiente. Consulte a documentação do seu framework para a ordem exata de carregamento.

Meu arquivo .env foi commitado acidentalmente no Git — o que devo fazer?

Rotacione imediatamente todas as credenciais expostas — elas devem ser consideradas comprometidas porque o histórico do git é permanente mesmo após a exclusão. Remova o arquivo com git rm --cached .env, adicione .env ao .gitignore e faça force-push para sobrescrever o histórico com git filter-branch ou BFG Repo Cleaner. Se o repositório é público ou foi clonado, assuma que todos os secrets estão comprometidos independentemente da reescrita do histórico.

Ferramentas Relacionadas para Desenvolvedores

• Contador de Tokens IA — conte tokens para GPT-4o, Claude, Gemini
• Decodificador e Inspetor de JWT — decodifique JSON Web Tokens com segurança no navegador
• Gerador de Docker Compose — gere docker-compose.yml com serviços
• Ver todas as ferramentas gratuitas para desenvolvedores