Para: devs independentes e pequenos operadores que não têm certeza de "qual é o mínimo" em segurança. Nenhum passo de ataque aqui — só os controles básicos considerados padrão do setor, em ordem de prioridade. Cada item liga para um artigo mais profundo, então você pode começar aqui e ler só o que precisar.
A visão deste site: não 'fazer tudo', mas 'preencher nesta ordem'
Uma pessoa só ou um time pequeno não consegue fazer tudo de uma vez — e é exatamente por isso que a ordem importa mais. Se a camada do topo (contas de administrador, domínio e e-mail) for sequestrada, todo controle abaixo dela perde o sentido (o atacante reinicia tudo como se fosse você). Avance da camada mais importante para baixo e você corta ao máximo sua probabilidade de incidente para o tempo que tem. Este artigo foi escrito não como conhecimento exaustivo, mas como uma lista para decidir rapidamente o que preencher a seguir.
Nível 0 — contas de administrador, domínio, e-mail
MFA · domínio · DNS · e-mail · pagamento
Nível 1 — segredos e código
manter segredos fora do git · detecção pré-commit · separação/rotação de chaves
Nível 2 — o próprio app
validação de entrada · auth/sessão · TLS/cabeçalhos · autenticação de e-mail
Nível 3 — corrigir, detectar, recuperar
CVEs de dependências · atualizações de SO · SSH/FW · logs · backups
Nível 0: proteja as contas de administrador, o domínio e o e-mail (primeiro)
Esta é a premissa de tudo o mais. Se seu domínio, e-mail ou painel de hospedagem for sequestrado, todo outro controle é anulado. O atacante redefine senhas como você, reescreve o DNS, entra no seu servidor. Então é isto que você tranca primeiro.
Implante MFA resistente a phishing
Proteja o e-mail com o máximo rigor
Guarde os códigos de recuperação e backup com segurança
Separe contas para reduzir pontos únicos de falha
Nível 1: não vaze segredos nem código
O incidente fundador deste site, e muitos por aí, vêm de uma falha aqui: segredos como arquivos .env e chaves de API escorregando para o código ou um repositório público.
Mantenha segredos fora do código-fonte e da documentação
.env e exclua-os do git (.gitignore). Não escrevê-los de jeito nenhum é o controle mais forte.Barre segredos por máquina antes do commit
Se vazou, presuma que vazou TUDO — rotacione tudo
Restrinja bem o escopo dos tokens e mantenha-os de vida curta
Auto-hospedando Git? Cuidado extra
Auto-hospedar porque o "público acidental" do GitHub te assusta não elimina o commit acidental. Sem nenhum bloqueio de segredos embutido do GitHub, um hook de segredos pré-commit é obrigatório no auto-hospedado. Veja Git auto-hospedado vs. GitHub: qual é mais seguro.
Nível 2: fortaleça o próprio app
O mínimo para a aplicação web que você expõe. O ponto não é deter ataques inéditos, mas fechar as vulnerabilidades comuns e bem conhecidas. Este site reformula cada uma em defesa nas páginas do glossário.
Nunca confie na entrada (previna vulnerabilidades comuns)
Acerte autenticação, sessão e acesso
Faça o TLS e os cabeçalhos de segurança valerem
Previna falsificação de e-mail
Nível 3: corrigir, detectar, recuperar
A base para "manter o dano pequeno e recuperar rápido mesmo após uma invasão." O monitoramento de dependências como o osv-scanner vive aqui.
Monitore CVEs de dependências por máquina, continuamente
Atualize o SO e o servidor automaticamente
Fortaleça o SSH e o firewall
Use menor privilégio para limitar até onde uma invasão se espalha
Backups 3-2-1 + uma restauração testada
Mantenha logs para conseguir notar anomalias
Por onde começar
"Tudo, agora mesmo" não é realista. Compare a ordem que as pessoas tendem a seguir com a que este site recomenda.
A ordem que as pessoas tendem a seguir (ineficiente)
- começar pelo trabalho chamativo de vulnerabilidades de aplicação
- deixar o MFA para "depois" indefinidamente
- ter backups mas nunca ter tentado uma restauração
- segredos estão no
.envmas não há hook de detecção
A ordem que este site recomenda
- Nível 0: proteja primeiro as contas de administrador, o e-mail e o domínio com MFA
- Nível 1: deter vazamentos de segredos estruturalmente (detecção pré-commit + política de rotacionar tudo)
- Nível 2: feche as vulnerabilidades comuns do app
- Nível 3: chegue ao "recuperável" com monitoramento de dependências, atualizações, backups com restauração testada
Este site também se defende nesta ordem
Este site aplica esta mesma base a si: a app e o banco de dados em contêineres separados, o banco só em uma rede interna (limitando o alcance do impacto na camada de contêiner/rede) / uma chave distinta por host / segredos nunca no git ou na documentação / monitoramento de CVE de dependências antes de cada deploy e diariamente / backups externos para um servidor separado / requisições externas por uma fronteira de segurança. Um site que ensina segurança não pode deixar vulnerabilidades na própria configuração, então rodamos esta ordem de prioridade em nós mesmos primeiro. Nosso incidente fundador, também, veio não de um ataque inédito, mas da falta de um destes controles básicos. Por isso continuamos dizendo: o básico antes do trabalho chamativo.
Leia a seguir
- Versão de organização / time: a base de segurança para organizações de médio a grande porte
- Auto-hospedagem: Git auto-hospedado vs. GitHub: qual é mais seguro
- Dependências: instalando e usando o osv-scanner · não ficar para trás nos CVEs
- Segredos: arquivos .env e segredos · incidente uma chave vazou e gerou cobrança fraudulenta
- Ferramentas: verificação de cabeçalhos de segurança · verificador de autenticação de e-mail · busca de CVE/KEV
- Framework: segurança por framework (aplique esta base à tecnologia que você de fato usa)
- O panorama: erros comuns são falhas de suposição (quatro crenças que continuam falhando)
- Cabeçalhos: cabeçalhos de segurança não são uma lista para empilhar (inclusive quais remover)