Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Guias de Segurança

#fundamentos de segurança#MFA#gestão de segredos#backups#preparo para a era da IA

A base de segurança para devs independentes e pequenos operadores: o conjunto-padrão completo

Checklist de base de segurança para dev independente e pequeno operador: os controles padrão do setor em um só lugar — MFA, higiene de segredos, monitoramento de CVE e backups —, ordenados de 'chaves do reino' a 'detectar e recuperar'.

Publicado 2026-06-11 Atualizado 2026-06-11 10 min de leitura

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ó a base considerada 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 é tudo. Se a camada do topo, as "chaves do reino", for sequestrada, todo controle abaixo dela perde o sentido (o atacante reinicia tudo como se fosse você). Preencha da base para cima 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 um mapa que permite decidir na hora o que preencher a seguir.

Nível 0 — chaves do reino

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

O mapa de prioridade deste site. Mais alto = 'se sequestrado, tudo desaba.' Preencha de cima para baixo.
minutos
até um segredo exposto ser explorado
buracos conhecidos
causa da maioria das invasões sérias
um ponto
chaves do reino caem = colapso total
ordem
a vitória com recursos finitos

Nível 0 — proteja as chaves do reino (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.

1

Implante MFA resistente a phishing

Exija MFA no registrador do domínio, DNS, painel de hospedagem, e-mail e pagamento. Força: passkeys/chaves de hardware (FIDO2) > app autenticador (TOTP) > SMS. SMS é quebrável via SIM swap — só como último recurso.
2

Trate o e-mail como a 'chave-mãe', guarde-o com mais rigor

A redefinição de senha de quase todo serviço cai no e-mail. Se o e-mail cai, tudo cai em cadeia. Só o e-mail já vale uma chave de hardware.
3

Guarde os códigos de recuperação e backup com segurança

Mantenha os códigos de recuperação de MFA em um gerenciador de senhas ou em um lugar fisicamente seguro. Perca-os e você se tranca para fora.
4

Separe contas para reduzir pontos únicos de falha

Evite senhas reutilizadas em contas críticas; torne cada uma única com um gerenciador de senhas para que uma invasão não se espalhe lateralmente.

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.

1

Mantenha segredos fora do código-fonte e da documentação

Separe chaves de API, senhas e strings de conexão em .env e exclua-os do git (.gitignore). Não escrevê-los de jeito nenhum é o controle mais forte.
2

Barre segredos por máquina antes do commit

Um hook pré-commit (gitleaks etc.) bloqueia fisicamente commits contendo segredos — a rede que a proteção de push do GitHub te dá, construída por você mesmo (→ Git auto-hospedado vs. GitHub).
3

Se vazou, presuma que vazou TUDO — rotacione tudo

A qualquer suspeita, revogue e reemita imediatamente as chaves/tokens afetados. Não deixe em "provavelmente está tudo bem." É o que mais funciona na resposta real a incidentes (→ uma chave vazou e gerou cobrança fraudulenta).
4

Restrinja bem o escopo dos tokens e mantenha-os de vida curta

Não emita um token todo-poderoso. Use menor privilégio, expiração curta e tokens por serviço para que um vazamento fique contido.

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 os buracos comuns e bem conhecidos. Este site reformula cada um em defesa nas páginas do glossário.

1

Nunca confie na entrada (feche os buracos clássicos)

Deter injeção de SQL, XSS, SSRF e path traversal impulsionados por entrada do usuário com escapamento, parametrização e listas de permissão.
2

Acerte autenticação, sessão e acesso

Defenda contra CSRF, imponha verificações de acesso contra IDOR (ver dados de outros) e configure controles de frame contra clickjacking.
3

Faça o TLS e os cabeçalhos de segurança valerem

Exija HTTPS, configure HSTS, CSP e companhia. Avalie seu próprio site com a verificação de cabeçalhos de segurança (construa o CSP com o construtor de CSP).
4

Previna falsificação de e-mail

Se você envia e-mail do seu próprio domínio, configure SPF/DKIM/DMARC. Encontre falhas com o verificador de autenticaçã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.

1

Monitore CVEs de dependências por máquina, continuamente

CVEs publicados e negligenciados são a principal causa de incidentes. Rode o osv-scanner ou o pnpm audit no CI/cron (→ não ficar para trás nos CVEs).
2

Atualize o SO e o servidor automaticamente

Automatize as atualizações de segurança do SO (unattended-upgrades etc.). Não negligencie patches do seu servidor Git e do middleware também.
3

Fortaleça o SSH e o firewall

Só chaves SSH (autenticação por senha desligada, sem login root direto), firewall aberto só nas portas necessárias, fail2ban para frear a força bruta.
4

Menor privilégio para encolher o raio da explosão

Rode serviços sem root, nunca exponha banco de dados/serviços internos, uma chave SSH distinta por host — para que uma invasão não se propague em cascata.
5

Backups 3-2-1 + uma restauração testada

Três cópias, duas mídias, uma externa. Criptografadas. E não só "está rodando" — realmente tente uma restauração uma vez.
6

Mantenha logs para conseguir notar anomalias

Retenha logs de acesso, autenticação e erro para que sinais estranhos fiquem visíveis. Quanto mais tarde você detecta, mais amplo o dano.

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 .env mas não há hook de detecção

A ordem que este site recomenda

  • Nível 0: tranque as chaves do reino primeiro (MFA, e-mail, domínio)
  • Nível 1: deter vazamentos de segredos estruturalmente (detecção pré-commit + política de rotacionar tudo)
  • Nível 2: feche os buracos clássicos 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: um servidor dedicado sem co-locação (separação do raio de explosão) / 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 ter buracos próprios — 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 de uma única falha nesta base. Por isso continuamos dizendo: a base antes do trabalho chamativo.

Leia a seguir

FAQ

QQual o primeiro controle de segurança que um dev independente deveria configurar?
A

Proteger as 'chaves do reino': coloque MFA resistente a phishing (passkeys/chaves de hardware) no registrador do domínio, DNS, painel de hospedagem, e-mail e contas de pagamento. Se essas forem sequestradas, todo outro controle é anulado — então elas vêm primeiro.

QTodos os controles de base são igualmente importantes?
A

Não. Há uma ordem clara. Este site recomenda preencher assim: 1) chaves do reino, 2) segredos e código, 3) o próprio app, 4) corrigir/detectar/recuperar. Com recursos finitos, de cima para baixo reduz mais os incidentes.

QMonitorar CVE de dependências conta como base?
A

Sim. Verificar continuamente, por máquina, as dependências em busca de vulnerabilidades conhecidas com osv-scanner ou pnpm audit é hoje padrão do setor. A maioria das invasões sérias vem de buracos conhecidos negligenciados (CVEs), não de ataques inéditos.