Como acompanhar a segurança de vários sites de clientes juntos

Você tem uma carteira de sites de clientes e quer detectar qualquer falha de segurança antes que o problema vire um incidente sério – mas se perde tentando checar tudo manualmente, o tempo todo. Não dá para abrir cada domínio, revisar cabeçalho e procurar arquivo sensível na mão, muito menos garantir quem é avisado se expirar um certificado ou mudar um redirecionamento.

O que realmente acontece quando uma brecha de segurança passa despercebida

Alguns dos problemas de segurança mais críticos em sites surgem de detalhes que são facilmente ignorados numa rotina manual. Quando um certificado TLS expira, o navegador mostra um aviso claro para o visitante, mas só se você acessar o site pela interface HTTPS — e isso pode passar batido num site que você e o cliente não acessam todo dia. O campo ‘expira em’ da cadeia de certificado está ali, mas ninguém recebe e-mail automático informando que o vencimento está próximo, a menos que algum sistema externo faça esse monitoramento.

Cabeçalhos de segurança HTTP, como Strict-Transport-Security, Content-Security-Policy e X-Frame-Options, podem simplesmente sumir do header de resposta após um deploy malfeito. Se você não coleta a resposta HTTP regularmente, o erro só aparece quando um atacante explora, ou quando o Google Search Console reclama de conteúdo misto ou de clickjacking. Confira o cabeçalho ‘Strict-Transport-Security’: se ele não estiver presente, ataques de downgrade ou man-in-the-middle se tornam possíveis, e ninguém avisa até o problema se realizar. Detalhei esse ponto em Como identificar e corrigir problemas de conteúdo misto em HTTPS.

A exposição inadvertida de arquivos como /.env ou /.git/config ocorre com mais frequência do que se imagina. Um GET no caminho /.env que retorna 200 pode expor credenciais de banco, SMTP e segredos de API em texto puro. Já um diretório .git exposto retorna informações detalhadas sobre o versionamento do site, auxiliando um possível atacante a entender a estrutura interna do código — e, em casos extremos, baixar o projeto inteiro para análise local.

SPF e DMARC são garantias de que seu domínio não está vulnerável a spoofing e phishing. Sem o registro TXT correspondente no DNS, e políticas DMARC do tipo ‘p=none’ ou ausentes, e-mails falsos podem ser enviados em nome do domínio do cliente. O resultado vai de reputação prejudicada à inclusão em listas negras, quando o alerta poderia chegar logo após a remoção acidental do registro.

Outra dor acontece com portas e serviços expostos além do necessário. Servidores com a porta 3306 (MySQL) aberta na internet, detectados por uma simples varredura, são um convite para scanners automatizados e bots mal-intencionados. Não precisa de ataque sofisticado: basta que o escaneamento seja feito no tempo certo para que a brecha seja denunciada, e, se não for corrigida, explorada. Tem um passo a passo disso em Plugin WordPress para varredura interna de segurança com selo.

O efeito real é sentir o impacto só quando o cliente avisa que perdeu posições no Google ou que teve e-mails bloqueados. Muitas vezes, o primeiro sintoma visível chega tarde demais, seja por um certificado vencido, seja por blacklist de reputação — e a recuperação, nesses casos, custa horas de retrabalho e desgaste com quem confia na sua gestão técnica.

O que checar primeiro para ganhar tempo e evitar surpresas desagradáveis

Diante de tantos pontos críticos, escolher a ordem das verificações faz diferença. O melhor caminho é priorizar riscos de maior impacto imediato, como a validade do certificado TLS, a presença dos principais cabeçalhos de segurança HTTP e a exposição de arquivos sensíveis. Uma mudança não documentada em deploy pode remover um cabeçalho em dezenas de sites de uma vez, e o índice de resposta HTTP dispara alertas só para quem monitora. Escrevi sobre isso em Como configurar alerta automático para mudanças em TLS e cabeçalhos.

Checar a política SPF no DNS é rápido e previne danos à reputação do domínio. Já as políticas DMARC merecem atenção porque a transição de ‘p=none’ para ‘p=quarantine’ ou ‘p=reject’ requer planejamento – e cada ambiente precisa ser acompanhado, garantindo que o registro continue no ar após qualquer alteração em provedores de DNS. Ignorar isso libera a porta para ataques de phishing e spoofing.

Cabeçalho Strict-Transport-Security ausente é detectado facilmente, mas requer olhar toda resposta HTTP após deploy. Content-Security-Policy e X-Frame-Options ajudam a bloquear cross-site scripting e clickjacking, mas a configuração depende do perfil de cada site – clone de CMS ou projeto sob medida.

A exposição de arquivos como .env ou diretórios .git/config ocorre até mesmo após atualizações de CMS ou de plugins, além de configurações erradas de backup ou FTP. Nem sempre o alerta vem do sistema: muitas vezes, é o Google que indexa um arquivo sensível e destrói tudo em questão de reputação. É fundamental automatizar a checagem desses caminhos.

Portas abertas além do HTTPS ou HTTP são facilmente esquecidas. Uma implantação de atualização do servidor pode reabrir a porta 3306 do MySQL ou a 21 do FTP, expondo serviços que nunca deveriam estar públicos. A checagem semanal pode ajudar, mas a diária é o ideal para sites com tráfego significativo ou aplicações críticas.

• Priorizar a validade do certificado TLS
• Verificar cabeçalhos Strict-Transport-Security, Content-Security-Policy e X-Frame-Options
• Conferir registros SPF e DMARC via DNS
• Testar resposta em /.env, /.git/config e outros arquivos sensíveis

Fazer isso manualmente para vários domínios não escala. A decisão prática é ter um fluxo de checagem automática, recebendo alerta por e-mail cada vez que a configuração de segurança é alterada ou quando uma nova vulnerabilidade aparece – só assim o prejuízo pode ser evitado.

Conferir a expiração do certificado de cada domínio um por um, revisar manualmente os cabeçalhos de cada página a cada novo deploy e depender do aviso do cliente para descobrir arquivo sensível exposto são tarefas que consomem tempo e nunca dão a garantia de agilidade que a responsabilidade técnica dos sites exige. O monitoramento contínuo permite receber alertas em tempo real a cada mudança detectada, organizar relatórios para cada domínio sem correr atrás dos dados e priorizar correção logo no começo do problema, antes de virar incidente. Para começar, basta fazer um scan gratuito em huntertwins.com.br, sem cadastrar cartão de crédito.

Como conferir todos esses pontos em um site do começo ao fim

1. Acesse o próprio domínio do site via navegador e clique no cadeado para verificar a data de expiração do certificado TLS.
2. Faça uma requisição usando curl ou outra ferramenta para ver o header HTTP da página principal, buscando pelas diretivas Strict-Transport-Security, Content-Security-Policy e X-Frame-Options.
3. Acesse o painel de DNS do domínio e valide a presença do registro TXT de SPF e se a política DMARC está configurada para p=quarantine ou p=reject, evitando p=none para domínios ativos.
4. Efetue um GET nos caminhos /.env e /.git/config e confira se a resposta HTTP retorna 403 (acesso proibido) ou 404; resposta 200 indica vazamento crítico de informação.
5. Utilize uma ferramenta de port scanning (como nmap) no endereço do site para checar se portas como 3306, 21 e 22 estão expostas à internet. Registre qualquer porta aberta que não deveria estar pública.
6. Faça uma pesquisa rápida com o domínio no Google Safe Browsing para verificar se o site apareceu em lista de malware ou phishing, conferindo se a reputação não foi prejudicada por arquivos ou scripts maliciosos.
7. Se o site usar WordPress, avalie instalar um plugin de varredura interna. Assim, é possível identificar alterações não autorizadas em arquivos core, plugins ou temas, além de detectar arquivos suspeitos criados por invasores.

Executar toda essa sequência em cada site sob sua responsabilidade toma tempo e exige disciplina. Muitos problemas só são percebidos com a repetição do processo ou quando algo muda sem aviso. Automatizar o disparo de alertas e centralizar as informações economiza horas a cada semana.

Os erros mais comuns que geram incidentes e sinais de que algo deu errado

Uma das falhas mais recorrentes é esquecer de renovar o certificado TLS de um dos domínios. O sintoma clássico é o navegador exibindo “Sua conexão não é privada” para visitantes: isso leva não só à fuga do usuário, mas também à perda de reputação e, em alguns casos, à indexação negativa no Google.

Remover ou esquecer o cabeçalho Strict-Transport-Security após um deploy faz o site aceitar downgrade de conexão, enfraquecendo a privacidade dos visitantes. O Google Search Console pode alertar sobre conteúdo misto, mas é raro que o cliente entenda a implicação disso antes que algum dado sensível vaze no caminho.

Ter o arquivo /.env respondendo status 200 na webserver significa que variáveis sensíveis estão expostas. Uma simples requisição GET é suficiente para um atacante capturar credenciais de banco, SMTP ou chaves de API. Isso já causou vazamento de dados corporativos e uso não autorizado de serviços terceirizados.

A ausência do registro SPF ou configuração DMARC inexistente faz o domínio ser usado por spammers para envio de phishing, implicando em e-mails legítimos bloqueados ou em restrições nos principais provedores. Muitas vezes, só se descobre o problema porque o cliente reclama que e-mails ficaram sem chegar ou foram diretamente para a caixa de spam.

• Navegador mostra aviso de certificado expirado
• Cabeçalho Strict-Transport-Security ausente após atualização
• GET em /.env retorna variáveis sensíveis
• Registro SPF/DMARC incompleto resulta em e-mails bloqueados

Outros sinais incluem portas inesperadas abertas na infraestrutura, visíveis em verificações externas com nmap, e arquivos de backup (.sql, .zip) deixados em áreas públicas por engano. Cada sintoma tem custo: desde o esforço para recuperar algo perdido, até a negociação com o cliente após um incidente que poderia ser evitado – quando bastava um alerta automatizado e uma resposta rápida.

Monitorar de verdade todos os sites sob sua administração exige rigor técnico e constância nas verificações. O detalhe que escapa hoje pode se tornar o próximo incidente amanhã, trazendo prejuízo e perda de confiança. A automatização dos alertas e relatórios centralizados é o próximo passo natural para quem precisa entregar segurança de verdade. O que muda no dia a dia é poder agir antes do problema chegar ao cliente.