Segurança de sites: guia prático
A maioria dos sites não é atacada de propósito. É encontrada por analisadores automáticos que varrem a internet à procura de vulnerabilidades conhecidas e palavras-passe fracas. Isso é boa notícia, porque significa que medidas básicas travam a maior parte dos ataques.
Este guia percorre essas medidas, aproximadamente por ordem de risco removido por esforço investido.
Acessos: onde começam quase todas as invasões#
Credenciais roubadas ou adivinhadas são a forma mais comum de sites pequenos caírem — mais do que qualquer vulnerabilidade técnica.
- Autenticação de dois fatores em todas as contas de administrador, sem exceção.
- Palavras-passe únicas geradas por um gestor; palavras-passe reutilizadas vazam noutro sítio e são testadas aqui.
- Remova contas de pessoas que saíram e de agências antigas — isto é quase sempre esquecido.
- Dê as permissões mínimas necessárias; um editor não precisa de ser administrador.
- Limite tentativas de entrada e bloqueie após falhas repetidas.
- Proteja também o que está à volta: alojamento, DNS, registador de domínio e e-mail. Perder o DNS é pior do que perder o site.
- Use SFTP ou chaves SSH, nunca FTP simples com palavra-passe.
O registador de domínio é a conta que mais frequentemente fica sem dois fatores e a que causa mais estragos se cair.
Atualizações e superfície de ataque#
Cada peça de software instalada é uma peça que tem de ser mantida atualizada. O trabalho de segurança mais barato é remover o que não usa.
| Medida | Porque conta |
|---|---|
| Núcleo do CMS atualizado | Vulnerabilidades conhecidas são procuradas em dias |
| Extensões atualizadas | A porta de entrada mais comum em sites WordPress |
| Remover extensões não usadas | Desativada não é segura; o código continua lá |
| Remover temas não usados | Mesma razão, ainda mais esquecido |
| Versão de PHP suportada | Versões antigas deixam de receber correções |
| Pacotes do servidor atualizados | Cabe ao alojamento em planos geridos — confirme |
| Dependências em código à medida | As bibliotecas também envelhecem |
Aplique atualizações em ambiente de testes e depois teste formulários e, numa loja, o percurso de pagamento. Uma atualização que parte um formulário em silêncio é um tipo próprio de avaria.
Proteção da aplicação e do servidor#
As medidas que cobrem vulnerabilidades técnicas em vez de acessos.
- Valide e limpe todas as entradas no servidor. Verificação no navegador é conveniência, não segurança.
- Use consultas preparadas em todo o acesso à base de dados — isto fecha a injeção de SQL.
- Escape a saída ao apresentar, para evitar scripting entre sites.
- HTTPS em todo o lado, com HSTS e certificado de renovação automática.
- Configure cabeçalhos de segurança: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Restrinja carregamentos por tipo e tamanho, e guarde-os fora da pasta pública.
- Desative a apresentação de erros em produção; as mensagens dizem ao atacante o que está a correr.
- Considere uma firewall de aplicação num CMS com muitas extensões.
Cópias e recuperação depois de uma invasão#
A segurança falha às vezes. O que acontece depois depende inteiramente do que preparou antes.
- Guarde cópias fora do servidor. Uma cópia na mesma máquina é cifrada ou apagada com o resto.
- Guarde várias gerações. Se a invasão só for detetada duas semanas depois, a cópia de ontem também está comprometida.
- Teste o restauro trimestralmente. É o passo que mais frequentemente falta.
- Numa invasão: tire o site do ar ou ponha-o em modo de manutenção antes de fazer mais alguma coisa.
- Mude todas as palavras-passe — CMS, alojamento, base de dados, FTP, DNS — antes de restaurar.
- Restaure a partir de uma cópia anterior à invasão, e atualize tudo antes de voltar a publicar.
- Descubra como entraram. Restaurar sem encontrar a causa significa que volta a acontecer.
Numa violação com dados pessoais existem obrigações de notificação com prazos curtos. Saiba antes quem avalia isso, não durante o incidente.
Perguntas frequentes
O WordPress é inseguro?
O núcleo é razoavelmente bem mantido; o risco está quase sempre em extensões, temas e palavras-passe fracas de administrador. Um site WordPress com dois fatores, poucas extensões e atualizações em dia está bem. Um site com quarenta extensões, metade sem atualização há dois anos, é uma questão de tempo.
Preciso de uma extensão de segurança?
São úteis para limitar tentativas de entrada, vigiar ficheiros e enviar alertas, mas não substituem nada da lista acima. Uma extensão de segurança num site com extensões desatualizadas e palavra-passe partilhada não resolve o problema real. Veja-a como detetor de fumo, não como construção resistente ao fogo.
O que faço se o meu site for invadido?
Tire-o do ar, mude todas as palavras-passe incluindo alojamento e DNS, e restaure a partir de uma cópia limpa anterior à invasão. Atualize tudo antes de voltar a publicar, e descubra como entraram — senão repete-se em semanas. Se houver dados pessoais envolvidos, há obrigações de notificação com prazos curtos.
O HTTPS protege o site de invasões?
Não, e é um mal-entendido frequente. O HTTPS cifra o tráfego entre visitante e servidor, o que impede interceção e manipulação em trânsito. Não faz nada contra palavras-passe fracas, extensões desatualizadas ou injeção de SQL. É necessário e completamente insuficiente.
segurança de sitessite invadidosegurança wordpresscertificado sslcabeçalhos segurançaproteger website
