"Vivo ouvindo que segurança importa, mas por onde eu sequer começo?" Este é o primeiro passo para desenvolvedores indie. Não para te assustar — só coisas em que você pode agir hoje, em ordem.
Por que começar pelos segredos (.env e chaves de API)
A maioria dos incidentes reais começa não com ataques sofisticados, mas com um segredo vazado. Os dois casos sobre os quais este site foi construído eram ambos vazamentos de segredo:
Proteja seus segredos e você previne a maioria dos incidentes comuns. Por isso começamos aqui.
O que é o .env (em 30 segundos)
O .env é um arquivo que reúne os valores secretos do seu app: a senha do banco de dados, chaves de API externas, a chave que criptografa as sessões. Como os segredos ficam juntos num arquivo só, um vazamento expõe todos de uma vez — então é o arquivo a proteger primeiro (→ Glossário: O que é o .env).
Onde os segredos podem ficar (.env, variáveis de ambiente, gerenciadores de segredos)
O .env não é o único lugar para segredos. Escolha conforme a escala e o uso.
| Onde | Melhor para | Cuidado com |
|---|---|---|
Um arquivo .env | Desenvolvimento local, um único servidor pequeno | Mantenha-o fora do Git e fora de diretórios públicos |
| Configuração de variáveis de ambiente da hospedagem (digitadas num painel) | Produção | Limite quem acessa o painel; mantenha os valores fora dos logs de build |
| Segredos de CI (testes e deploy automatizados) | Automação como GitHub Actions | Ferramentas externas executadas na CI conseguem ver os valores; passe chaves só com os direitos necessários |
| Um gerenciador de segredos | Várias pessoas ou vários servidores | Mantenha o acesso de leitura mínimo e faça rotação regular |
Para segredos de CI, o incidente da Codecov em 2021 é uma referência útil. Uma ferramenta externa executada na CI foi adulterada, e segredos guardados em variáveis de ambiente da CI foram levados (→ o incidente da Codecov).
Chaves que você pode publicar e chaves que não pode
Algumas chaves de API foram feitas para ir dentro de navegadores ou apps móveis; outras são só para servidores. Suponha que qualquer coisa enviada a um navegador pode ser lida por qualquer pessoa.
| Exemplo | Pode publicar? | Por quê |
|---|---|---|
Chave publicável da Stripe (começa com pk_) | Sim | A documentação diz que ela pode ir no código do front-end; ela não consegue fazer operações sensíveis como criar cobranças |
Chave secreta (sk_) ou chave restrita (rk_) da Stripe | Não | Elas permitem operações do lado do servidor; a documentação recomenda chaves restritas com permissões reduzidas |
Variável de ambiente do Next.js com NEXT_PUBLIC_ | Publicada | O valor é embutido no JavaScript do navegador no momento do build |
Variável de ambiente do Next.js sem NEXT_PUBLIC_ | Não publicada (só servidor) | Coloque os valores secretos aqui |
Em dúvida, veja na documentação oficial do serviço se a chave pode ser usada no lado do cliente. Se ela não disser, trate-a como uma chave que você não pode publicar.
O que significa um vazamento de chave de API
Uma chave de API é "uma sequência de caracteres que faz um serviço tratar quem a usa como se fosse você." Em mãos erradas, o dano se espalha assim.
Chaves roubadas são frequentemente revendidas e abusadas com atraso — "nada acontece no começo, depois uma fatura surpresa" é o padrão clássico. Então "depois que você nota" é tarde demais; o ponto é não vazá-las logo de início.
O que fazer se uma chave pode ter vazado
Apagar a chave do código não a desativa. O relatório de 2025 da GitGuardian concluiu que 70% dos segredos vazados em repositórios públicos em 2022 ainda eram válidos na data do relatório. Responda nesta ordem.
- Revogue ou rotacione a chave no painel do emissor. Se o serviço oferecer um período de transição, encerre a chave vazada "agora"
- Configure a nova chave em produção e confirme que o app funciona
- Verifique no histórico de uso e na cobrança do emissor se há atividade que não foi sua
- Remover a chave dos arquivos e do histórico do Git pode esperar até depois da revogação (só apagar não detém quem já tem uma cópia)
Os detalhes estão em 540.000 credenciais publicadas no GitHub ainda são válidas. O GitHub ativa por padrão a "proteção de push" (push protection), que impede uma conta pessoal de fazer push de segredos para um repositório público, mas ela não pega todo tipo de segredo.
Quatro hábitos para começar hoje
Nada difícil. Só estes quatro.
Não o exponha
Nunca coloque o .env ou o corpo do app num diretório visível pela web (a raiz web). Exponha só o public/. Passos concretos para hospedagem compartilhada: este guia.
Não o comite
Adicione .env* ao .gitignore (permita !.env.example); compartilhe só um exemplo sem valores. Uma vez comitado, é recuperável do histórico, então mantenha-o fora desde o início.
Rotacione tudo se vazar
Não só uma chave — rotacione todo segredo que poderia ter vazado. Ordem: API externa / OAuth → chaves de criptografia → e-mail → DB. Aja como se tivessem sido vistos.
Autoverifique
De vez em quando confirme que /.env não pode ser aberto de fora (abaixo).
Autoverificação (só contra domínios que você possui)
# Um 200 com corpo significa que está exposto. 403/404 está ok por enquanto.
curl -sI https://seu-dominio/.env | head -1
curl -sI https://seu-dominio/.git/config | head -1Verificar isto a cada deploy pega erros de posicionamento cedo.
Além do que é visível de fora, verifique também o Git e a saída do build (execute no seu próprio repositório).
# O .env já foi comitado alguma vez? (qualquer saída significa que sim, em algum momento)
git log --all --oneline -- .env
# arquivos parecidos com env que o Git rastreia agora (qualquer coisa além de .env.example merece atenção)
git ls-files | grep -i "env"Para confirmar que nenhuma chave vai para o navegador, procure os primeiros caracteres da chave na pasta de saída do build (no Next.js, .next/static). Você também pode colar o código no scanner de vazamento de segredos antes de publicar (nada é enviado a lugar nenhum).
Erros comuns vs o primeiro passo certo
Comum
- "Funciona", então jogar o
.envbem embaixo de public - "Apago depois", então comitar o
.envuma vez - Rotacionar só a única chave que você viu sendo abusada
O primeiro passo certo
- Corpo do app fora da raiz web, expor só
public/ - Excluir o
.envvia.gitignoredesde o início - Se vazar, rotacionar todo segredo do env
Próximos passos
A partir daqui, os próximos tópicos são "os padrões arriscados na sua stack" e "um sistema para não ficar para trás nos CVEs publicados". Sem pressa, um de cada vez.
Fontes
- Next.js, "How to use environment variables in Next.js" (16.x) — nextjs.org
- Stripe Docs, "API keys" — docs.stripe.com
- Laravel 13.x, "Configuration" (Environment File Security) — laravel.com
- GitHub Docs, "About push protection" — docs.github.com
- GitGuardian, "The State of Secrets Sprawl 2025" — blog.gitguardian.com
Leia a seguir
- Depois de um vazamento: 543.699 credenciais expostas no GitHub ainda são válidas — por que você precisa revogar, não só apagar
- O vazamento do Gyazo (setembro de 2026): o que vazou e o que os usuários devem fazer hoje
- Glossário: O que é o .env · O que é um CVE · O que é RCE
- Defesa: Mantenha o .env fora da web pública · Higiene de CVE no Next.js
- Incidente: Uma chave de API roubada cobrada por fraude
- Incidente: uma chave roubada fez a conta ser banida
- Cadeia de suprimentos: quando um único npm install rouba suas credenciais (código de terceiros rodando no ambiente onde suas chaves estão guardadas)