Guias de Segurança
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Tem um token ou arquivo de credenciais parado no diretório público da sua web (webroot)? O erro clássico em que qualquer um pode baixá-lo pela URL, a armadilha da propagação por template em que todo site tem o mesmo buraco e como auditar seu próprio servidor e fechá-lo — pela ótica operacional deste site.
Para: qualquer pessoa que rode vários sites em hospedagem compartilhada/alugada ou em um VPS, fazendo deploy em diretórios públicos (public/, public_html/, htdocs/ etc.). Nenhum passo de ataque — só auditar o seu próprio servidor e fechar os buracos. Para proteger o próprio .env, veja protegendo o .env em hospedagem compartilhada.
A visão deste site: onde você coloca É o controle de acesso
Segredos vazam mais por acidentes de posicionamento do que por ataques engenhosos. O webroot é "um lugar de onde qualquer um pode vir baixar pela URL." Coloque um segredo ali e até a senha de servidor mais forte fica sem sentido. A base deste site é manter segredos fora tanto do webroot quanto do git (→ guardando segredos com segurança). A ideia é simples: o diretório público é uma prateleira pública. Coloque ali só coisas que você não se importa que sejam vistas.
public/ = baixável por qualquer um via URL
OK colocar
imagens, CSS, JS — assets públicos
Nunca colocar
.env, token.json, .sql, .git, .bak
Acima da raiz do app = não servido
Coloque aqui
segredos, tokens, credenciais, backups. Permissão 600 (leitura só do dono). Inalcançável por URL.
Por que "resquícios no diretório público" acontecem
O padrão comum é um arquivo colocado por conveniência, ou um que veio dentro de um boilerplate, ficando silenciosamente público.
Por exemplo, um JSON guardando um token de acesso para uma integração de terceiros fica sob public/ por muito tempo — e se for de um template compartilhado, o mesmo arquivo é copiado para o mesmo ponto em muitos sites, então todos compartilham o mesmo buraco. Corrigir um site não adianta nada se os outros estão abertos. Igualmente perigosos: .env esquecidos, backups de banco de dados (.sql), um diretório .git, backups de editor (*.bak) e atalhos (relacionado: path traversal · um .env inteiro exposto).
Audite o seu próprio servidor
Primeiro, revele mecanicamente "quaisquer arquivos com cara de segredo no meu próprio diretório público." Isto é inspecionar os seus próprios ativos, não espiar o site de outra pessoa.
Procure sob os diretórios públicos por arquivos com cara de segredo
public/ (JSON de token/credenciais, .env, chaves, atalhos).Presuma propagação — amplie para todo host e site
Decida por arquivo se ele realmente precisa ser público
# audita sob os seus próprios diretórios públicos (inspecionando os seus próprios ativos)
find ~ -path '*/public/*' \( -iname '*token*.json' -o -iname '*credential*.json' \
-o -iname '*.bak' -o -iname '*.sql' -o -iname '.env*' \) 2>/dev/null
# um diretório .git exposto também é perigoso
find ~ -path '*/public/*/.git' -maxdepth 8 2>/dev/nullO que fazer quando você acha um
Faça três coisas como um conjunto — remover, revogar, mover. Pule qualquer uma e o buraco não fica totalmente fechado.
Remova do webroot para que a URL não consiga baixá-lo
Revogue/reemita qualquer chave ou token que possa ter vazado
Mantenha segredos fora do webroot com permissão 600
O posicionamento em que as pessoas caem (perigoso)
- um token JSON para uma integração fica em
public/ - um arquivo de segredo que veio no boilerplate permanece público
- backups (
.sql/.bak) ou.gitdeixados sob o diretório público - corrigir um site e considerar "resolvido"
O posicionamento correto
- o diretório público contém só coisas que podem ser públicas
- segredos ficam fora do webroot com permissão 600
- extensões sensíveis têm o serviço negado
- ache um e audite todo host e site
Faça de 'só coisas seguras para o público' uma regra permanente
Regras vencem correções pontuais. Decida que o diretório público é uma prateleira pública e, por regra, nunca coloque ali segredos, backups, dados de controle de versão (.git) ou arquivos de configuração. Ao atualizar um boilerplate, retire o segredo do próprio template — senão todo site que você produzir em massa a seguir continua copiando o mesmo buraco.
O que este site faz por conta própria
A base deste site é manter segredos — chaves, tokens, strings de conexão — fora tanto do diretório público quanto do repositório de código. Os artefatos de deploy contêm apenas assets públicos construídos; os segredos ficam como variáveis de ambiente do ambiente de execução, em um lugar que não é servido. O motivo: a classe de incidente deste artigo é o clássico de manual "um resquício, e uma URL vaza tudo." Projetamos o posicionamento em si como controle de acesso e rodamos esta auditoria na mesma cadência do inventário de resposta a vulnerabilidades.
Leia a seguir
- Stacks: protegendo o .env em hospedagem compartilhada · o playbook de resposta a vulnerabilidades (inventário)
- Glossário: arquivos .env e segredos · path traversal
- Incidente: um .env inteiro exposto
- Armazenamento: guardando segredos com segurança
FAQ
QPor que colocar arquivos em um diretório público é perigoso?
Qualquer coisa no diretório público da web (webroot — public/, public_html/ etc.) pode ser baixada por qualquer um que acesse sua URL. Um JSON de token/credenciais esquecido, um .env, um backup ou um arquivo de chave é recuperado antes de alguém notar, levando a dano imediato. O diretório público deve conter apenas coisas que é seguro serem públicas.
QSe eu achar um em um site, devo verificar os outros?
Sim. Se você produz sites em massa a partir de um template ou boilerplate compartilhado, o mesmo resquício normalmente se propaga por todos eles. Ache um e audite todos os sites e hosts de mesma origem.
QO que faço quando acho um?
1) Remova o arquivo do webroot para que retorne 404 pela URL. 2) Renove/revogue qualquer token ou chave que possa ter vazado (presuma que vazou). 3) Daqui em diante, mantenha segredos fora do webroot com permissão 600 (leitura só do dono). Faça os três como um conjunto.