Como achar falhas de segurança em sites: checklist

Roteiro para auditar o seu próprio site: do inventário aos logs, com ferramentas livres e o que fazer com cada falha encontrada. Só para site seu ou autorizado.

Por Redação Eleven Host · @robson.direitodigital · Atualizado em 18 de outubro de 2026 · 9 min de leitura

Como achar falhas de segurança em sites? Siga um roteiro do mais leve ao mais pesado: liste o que roda, confira certificado, cabeçalhos e arquivos expostos, revise contas e atualizações, rode uma varredura e leia os logs. Faça isso só no seu site.

Antes de começar: o limite legal

A lei brasileira trata invasão de dispositivo informático como crime. Testar um site sem permissão pode cair nessa conta, mesmo que a intenção seja "só olhar" ou avisar o dono.

Por isso, este roteiro vale para duas situações: o site é seu, ou o dono autorizou por escrito, dizendo o que pode ser testado e em que período. Se você presta serviço a um cliente, peça essa autorização antes de rodar qualquer ferramenta.

Outro ponto: este guia ensina a identificar e corrigir. Não mostramos como explorar uma falha. Achou algo? O próximo passo é consertar, não testar até onde dá para ir.

Passo 1: faça o inventário do que está no ar

Não dá para proteger o que você não sabe que existe. Antes de testar, escreva uma lista com tudo que responde em nome do seu domínio:

• o sistema do site (por exemplo, WordPress) e a versão dele;
• cada plugin, tema e biblioteca instalados, com a versão;
• subdomínios, inclusive os esquecidos (um teste.exemplo.com de dois anos atrás);
• painéis de administração, bancos de dados e serviços acessíveis de fora;
• quem tem acesso a cada coisa.

Passo 2: verificações passivas, só olhando

Estas checagens apenas leem o que o site já mostra a qualquer visitante. São as mais seguras para começar.

Certificado e versões do TLS

Veja a validade do certificado e quais versões do protocolo o servidor aceita. No terminal:

echo | openssl s_client -connect exemplo.com:443 -servername exemplo.com 2>/dev/null | openssl x509 -noout -dates

echo | openssl s_client -connect exemplo.com:443 -servername exemplo.com -tls1_2 2>/dev/null | grep -E "Protocol|Cipher"

echo | openssl s_client -connect exemplo.com:443 -servername exemplo.com -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"

A primeira linha mostra as datas de início e fim do certificado. A segunda confirma se o TLS 1.2 responde; troque por -tls1_3 para o 1.3. A terceira testa o TLS 1.1, uma versão antiga: se a versão for aceita, a linha Cipher mostra a cifra negociada; se for recusada, ela mostra (NONE) ou 0000. Se nada aparecer, o OpenSSL do seu computador pode não ter suporte a ela; esse teste sozinho não permite concluir. Se o certificado está perto de vencer, ou se uma versão que você não esperava responde, corrija. Para entender os nomes, leia o que é certificado SSL.

Cabeçalhos de segurança HTTP

Cabeçalhos são avisos que o servidor envia ao navegador junto com a página. Alguns ajudam a limitar estragos se algo der errado. Para ver todos:

curl -sI https://exemplo.com

Procure por estes, e anote os que faltam:

• Strict-Transport-Security: manda o navegador usar sempre HTTPS;
• Content-Security-Policy: define de onde a página pode carregar scripts e imagens;
• X-Frame-Options: impede que outro site coloque o seu dentro de um quadro;
• X-Content-Type-Options: evita que o navegador adivinhe o tipo de um arquivo.

Arquivos que não deveriam estar públicos

Falhas simples e graves nascem de arquivos esquecidos na pasta do site. Teste, no seu domínio, se estes endereços respondem:

• /.git/HEAD: sinal de que a pasta de controle de versão está exposta;
• /.env: arquivo de configuração que pode conter senhas;
• /phpinfo.php: página de diagnóstico que revela a configuração do servidor;
• backups esquecidos, como site.zip ou backup.sql;
• listagem de diretório: uma pasta que mostra a lista de arquivos em vez de uma página.

curl -s -o /dev/null -w "%{http_code}\n" https://exemplo.com/.env

O comando imprime o código de resposta. Um 404 ou 403 é o esperado. Um 200 pede atenção: abra o endereço no navegador e veja o conteúdo, porque alguns sites devolvem 200 para qualquer endereço, com uma página de erro bonita.

Quer fazer essa auditoria num servidor onde você controla a configuração e lê os logs? Ver os planos de VPS

Passo 3: contas e acessos

Uma invasão pode não passar por falha de software: entra pela porta da frente, com uma senha que alguém já usou em outro lugar. Revise:

• usuários de ex-funcionários, ex-freelancers e de quem já saiu do projeto: desative;
• contas de administrador: deixe só quem realmente precisa;
• senhas padrão de instalação, de bancos de dados e de painéis: troque;
• verificação em duas etapas nos acessos de administração: ative onde existir;
• senhas de FTP guardadas em e-mail ou planilha: troque.

Exemplo prático: o blog de uma empresa tem seis administradores e dois são de pessoas que saíram. Desativar essas contas fecha dois caminhos de entrada. O guia de 10 medidas de segurança para sites aprofunda senhas, acessos e proteção do login.

Passo 4: atualizações pendentes

Com o inventário em mãos, compare cada versão com a mais recente indicada pelo desenvolvedor do software. Plugin abandonado pelo autor é alerta por si só: troque por um mantido. O que você não usa, remova.

Antes de atualizar, faça uma cópia. Se algo quebrar, você volta atrás. O roteiro de backup de site mostra como.

Passo 5: formulários e envio de arquivos

Todo lugar onde um visitante digita ou envia algo é uma porta a ser examinada. Liste os formulários do site e pergunte, para cada um:

• o que ele aceita? Só texto, ou também arquivos?
• se aceita arquivos, quais tipos? Um formulário de currículo que aceita qualquer extensão é um problema;
• o arquivo enviado fica numa pasta onde o servidor pode executá-lo como programa?
• há limite de tamanho do arquivo?

Você descobre isso lendo a configuração do site e a documentação do plugin que cria o formulário. Se a documentação não deixa claro, trate como ponto de atenção e peça ajuda a quem mantém o site.

Passo 6: varredura com ferramenta livre, no seu ambiente

Depois do olhar manual, use ferramentas livres. Aponte-as apenas para o seu próprio site e servidor, de preferência num horário de pouco movimento, porque varreduras geram tráfego.

OWASP ZAP: comece pela varredura passiva

O OWASP ZAP é um software livre de análise de aplicações web. Na varredura passiva, ele só observa as respostas do seu site enquanto você navega por ele e aponta problemas, como cabeçalhos ausentes e cookies sem proteção. Não envia ataques. Comece sempre por esse modo.

nmap: quais portas do seu servidor estão abertas

O nmap mostra quais portas respondem num servidor. Use no IP do servidor que é seu:

nmap -sV 203.0.113.10

O resultado lista as portas abertas e o serviço que responde em cada uma. Compare com o que deveria estar aberto. Banco de dados aberto para a internet merece ação: feche no firewall ou restrinja a quem precisa.

Passo 7: leia os logs

Os logs registram o que aconteceu no servidor. Em Debian e Ubuntu com Nginx, os caminhos padrão são estes (confirme no seu sistema; outras distribuições e o Apache usam outros):

sudo grep "Failed password" /var/log/auth.log | tail -n 20

sudo grep " 404 " /var/log/nginx/access.log | tail -n 20

A primeira linha mostra as últimas tentativas de acesso remoto com senha errada. A segunda, os últimos pedidos a endereços que não existem. Uma sequência de erros 404, vindos do mesmo endereço IP e pedindo arquivos como /.env ou /wp-login.php, indica alguém procurando arquivos expostos. Isso, sozinho, não é invasão.

Se os logs mostrarem sinais de que alguém já entrou, pare este roteiro e siga o guia de segurança para quem tem e para quem visita sites, que trata da resposta a uma invasão.

O que fazer com cada achado

Ordene pelo risco: o que dá acesso ao site ou aos dados vem antes do ajuste fino.

• Arquivo .env, .git ou backup acessível: tire do ar primeiro, troque todas as senhas e chaves que estavam lá;
• Usuário antigo com acesso: desative a conta e revise o que ela alterou por último;
• Plugin ou sistema desatualizado: faça cópia, atualize, teste o site; se o plugin está abandonado, substitua;
• Porta de banco de dados aberta para a internet: feche no firewall ou libere só os endereços necessários;
• Cabeçalhos ausentes: adicione na configuração do servidor, um por vez, testando o site depois de cada um;
• Certificado perto do vencimento: renove e confira se a renovação está agendada;
• Tentativas de login em massa: limite as tentativas, ative a verificação em duas etapas e restrinja o acesso de administração.

Depois de corrigir, reconfira: repita a checagem que encontrou o problema e veja se ele sumiu. Anote a data e o que foi feito.

Quando repetir a auditoria

Um site muda: novos plugins, novas contas, novos subdomínios. Marque uma data fixa para repetir o roteiro completo e anote-a. Repita também depois de grandes mudanças, como trocar de servidor, de sistema ou de equipe. Contas, atualizações e logs podem entrar numa rotina mais curta.

Num servidor administrado por você, o roteiro inteiro fica ao seu alcance, inclusive logs e configuração. Isso vem com a responsabilidade de cuidar de atualização, backup e segurança (confirme com a equipe o que a Eleven faz).

Tem uma dúvida sobre o seu serviço na Eleven Host? Abrir um chamado

Perguntas frequentes

Posso testar o site de um concorrente ou de um conhecido?

Não sem autorização por escrito do dono. A lei brasileira trata invasão de dispositivo como crime, e testar sem permissão pode ser enquadrado nisso. Para estudar, monte um site de teste seu.

Preciso ser especialista para seguir este roteiro?

Os passos 1, 3, 4 e 5 pedem atenção, não conhecimento avançado. Os passos 2, 6 e 7 usam o terminal, e os passos 6 e 7 pedem acesso ao servidor. Se não for o seu caso, peça a quem administra o site para rodá-los.

A varredura pode derrubar o meu site?

Pode sobrecarregar um servidor pequeno, principalmente varreduras ativas. Por isso, comece pelo modo passivo, escolha um horário de pouco movimento e tenha um backup recente.

Achei uma falha e não sei corrigir. O que faço?

Anote o que viu (endereço, comando, resultado) sem mexer em mais nada, e leve ao desenvolvedor ou à equipe que mantém o site. Se o site roda em um serviço da Eleven, abra um chamado com essas informações e pergunte o que a equipe pode orientar.