Saltar para o conteúdo
Ajuda de emergênciaComeçar agora
LISTA DE VERIFICAÇÃO

Lista de verificação de segurança do site

Uma verificação de segurança do site deve responder a uma pergunta prática: atacantes, browsers, motores de pesquisa ou visitantes casuais conseguem ver algo que a sua equipa não queria expor? Este scanner cobre os controlos públicos que muitas vezes determinam se um site transmite confiança ou se torna um alvo fácil.

TLS e SSL

Confirma que o site serve HTTPS, redireciona o HTTP simples e tem um certificado válido que abrange o nome do anfitrião.

  • Disponibilidade de HTTPS
  • Validade do certificado e cobertura do nome do anfitrião
  • Redirecionamento HTTP para HTTPS
  • Conteúdo misto e formulários inseguros

Cabeçalhos de segurança

Revê proteções aplicadas pelo browser que reduzem XSS, clickjacking, MIME sniffing e riscos de downgrade.

  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Frame-Options
  • Permissions-Policy

Verificações de exposição

Procura ficheiros e metadados públicos que frequentemente revelam credenciais, dados de controlo de versão, detalhes de implementação ou caminhos sensíveis.

  • Ficheiros.env e backups
  • Caminhos de controlo de versão
  • Listagens de diretórios
  • Divulgações em robots.txt

Configuração do servidor

Assinala divulgação tecnológica desnecessária e comportamentos do servidor que facilitam ataques dirigidos ou exploração.

  • Fuga no cabeçalho Server
  • Divulgação em páginas de erro
  • Postura CORS
  • Métodos HTTP de risco

Sinais comuns de vulnerabilidade

Usa verificações públicas não destrutivas e sondagens específicas de frameworks para identificar padrões de risco conhecidos sem modificar o site.

  • Indicadores de open redirect
  • Sinais de React Server Components (React2Shell)
  • Endpoints de depuração expostos
  • Exposição de painéis de administração

Boas práticas operacionais

Verifica as bases públicas que apoiam a divulgação responsável, a integridade de scripts de terceiros e a segurança das sessões.

  • security.txt
  • Subresource Integrity em recursos de CDN
  • Atributos Secure, HttpOnly e SameSite nos cookies

Como funciona a verificação de segurança do site

A verificação obtém o URL que indicar e executa 27 verificações sobre essa resposta e sobre uma lista fixa de caminhos conhecidos no mesmo anfitrião. A maioria das verificações envia pedidos GET, HEAD ou OPTIONS; a verificação React2Shell envia pedidos POST de deteção com um conteúdo inofensivo. Os dados do certificado vêm dos registos públicos de Certificate Transparency.

Encriptação

  1. Validade, expiração e cobertura do nome do anfitrião no certificado
  2. Redirecionamento HTTP para HTTPS
  3. Conteúdo misto em páginas HTTPS
  4. Atributos Secure, HttpOnly e SameSite nos cookies de sessão
  5. Formulários que submetem para URLs HTTP

Cabeçalhos de segurança do browser

  1. Strict-Transport-Security: max-age, includeSubDomains e preload
  2. Content-Security-Policy sem unsafe-inline, unsafe-eval nem wildcards
  3. Proteção contra clickjacking (X-Frame-Options ou frame-ancestors)
  4. X-Content-Type-Options: nosniff
  5. Referrer-Policy
  6. Permissions-Policy
  7. Origens CORS wildcard e null

Exposição de informação

  1. Ficheiros.env, de configuração, dumps de bases de dados e ficheiros de dependências
  2. Cópias de segurança (.bak,.old,.orig,.swp e semelhantes)
  3. Source maps de JavaScript públicos
  4. Metadados Git, SVN, Mercurial e Bazaar
  5. Divulgação de versões do servidor e da tecnologia
  6. Caminhos sensíveis listados no robots.txt

Configuração do servidor

  1. Listagem de diretórios
  2. Painéis de administração e de início de sessão acessíveis
  3. Endpoints de depuração, estado e métricas
  4. Métodos TRACE, PUT e DELETE

Sinais de vulnerabilidades conhecidas

  1. Sinais de resposta de React Server Components (React2Shell)
  2. Open redirects através de parâmetros de redirecionamento comuns
  3. Stack traces e detalhes da framework em páginas de erro

Práticas de segurança

  1. security.txt com os campos Contact e Expires
  2. Subresource Integrity em scripts e folhas de estilo de CDN

Como é calculada a nota

A pontuação começa em 100. Uma verificação falhada desconta 25, 15, 10 ou 5 pontos consoante a severidade seja crítica, alta, média ou baixa, e um aviso desconta 15, 10, 5 ou 2. As verificações que não foi possível concluir e os resultados informativos não alteram a pontuação. A+ corresponde a 90 ou mais, A a 80-89, B a 65-79, C a 50-64, D a 35-49 e F a menos de 35.

O que esta verificação não analisa

Um resultado limpo significa que estas verificações públicas passaram no momento da análise. Não é uma avaliação de segurança completa, por isso planeie testes separados para as áreas abaixo.

  • Páginas autenticadas, percursos de utilizadores com sessão iniciada e lógica de negócio
  • Páginas além do URL indicado e da lista fixa de caminhos conhecidos
  • Versões do protocolo TLS e conjuntos de cifras
  • Versões de software instaladas face a bases de dados de vulnerabilidades, exceto os sinais React2Shell
  • Testes de injeção, força bruta ou negação de serviço
  • Estado de malware, listas de bloqueio e reputação
  • Registos DNS e de autenticação de e-mail, que a verificação de segurança de e-mail abrange

O que significa cada resultado

A nota A-F resume a postura pública geral, mas o estado de cada verificação é mais importante do que a letra. Priorize primeiro falhas críticas e de alta severidade, depois corrija avisos que enfraquecem as proteções do browser.

Passou

O controlo está presente ou configurado de forma a cumprir a base do scanner.

Aviso

O controlo existe mas está incompleto, fraco, demasiado permissivo ou sem contexto para uma aprovação limpa.

Falhou

O scanner encontrou um controlo ausente ou arriscado que deve ser corrigido antes de usar o site para fluxos sensíveis.

Erro

A verificação não foi concluída de forma fiável, normalmente porque o alvo bloqueou o pedido, excedeu o tempo limite ou devolveu uma resposta inesperada.

Vulnerabilidades comuns que isto deteta

A maioria das falhas de segurança em sites não é exótica. São ficheiros expostos, políticas fracas do browser, garantias de transporte em falta ou configurações predefinidas que nunca foram revistas depois do lançamento.

HSTS em falta

Risco: Os browsers podem permitir ataques de downgrade ou acesso HTTP acidental depois de um utilizador visitar o site.

Próximo passo: Sirva todo o tráfego por HTTPS primeiro, depois ative um max-age HSTS longo com includeSubDomains quando os subdomínios estiverem prontos.

Content-Security-Policy fraca ou ausente

Risco: Scripts injetados têm mais margem para executar se surgir uma falha XSS na aplicação.

Próximo passo: Comece com CSP em report-only, remova uso de scripts inline inseguros quando prático e depois aplique uma política de produção restrita.

Exposição a clickjacking

Risco: Atacantes podem conseguir incorporar páginas sensíveis em frames e enganar utilizadores para executarem ações indesejadas.

Próximo passo: Use frame-ancestors em CSP ou X-Frame-Options nas páginas que nunca devem ser incorporadas.

Ficheiros de ambiente ou backup expostos

Risco: Ficheiros públicos de configuração podem revelar credenciais, URLs internos, chaves API ou detalhes de implementação.

Próximo passo: Remova ficheiros expostos, substitua quaisquer credenciais expostas e bloqueie extensões sensíveis e dotfiles na edge.

Próximos passos depois da verificação

Se isto for mais do que um cabeçalho em falta, o próximo passo é um operador, não outro scan. Ligue as suas ferramentas de segurança à Plataforma Vigilbase ou fale connosco sobre Managed Cloudflare.

Comece a utilizar a Plataforma Vigilbase

Ligue as ferramentas de segurança que já paga ao sistema operativo da cibersegurança e deixe o agente Vigil investigar o que importa.

Abrir recurso

Fale connosco sobre Managed Cloudflare

Se isto for mais do que um cabeçalho em falta, o próximo passo é um operador, não outro scan.

Abrir recurso

Perguntas frequentes sobre a verificação de segurança do site

O que testa a verificação de segurança do site?

Verifica a configuração TLS e SSL, cabeçalhos HTTP de segurança, HSTS, CSP, risco de conteúdo misto, ficheiros expostos, fuga de informação do servidor, divulgações em robots.txt e vários sinais públicos de vulnerabilidade.Os resultados abrangem o URL público e os sinais observados durante a análise. Não abrangem todas as rotas autenticadas, os serviços internos ou os riscos da lógica de negócio.Verificador de Cabeçalhos de Segurança HTTPGuia prático de proteção de sites

A verificação é segura para executar num site em produção?

Sim, quando tem autorização para testar o alvo. A verificação pública é não destrutiva, mas o fluxo verificado de vulnerabilidades pode enviar pedidos de sondagem específicos de frameworks, incluindo React e Next.js, para confirmar exposição. Não faz brute force a logins nem modifica o site alvo.Acorde primeiro com o responsável o alvo, os testes permitidos e o momento da execução. As sondagens não destrutivas podem ainda assim atingir código da aplicação em produção e devem ser consideradas no plano de testes.Requisitos de acesso e verificação das ferramentasVerificação de exposição React2Shell

Porque tenho de verificar o meu e-mail antes da verificação?

A verificação ajuda a prevenir abuso e confirma o acesso ao endereço de email usado no pedido. Não prova a propriedade do alvo nem a autorização para o testar.Submeta apenas sistemas que lhe pertençam ou que tenha autorização explícita para testar. Não considere uma verificação de email concluída como autorização do responsável por um sistema de terceiros.Requisitos de acesso e verificação das ferramentasPrivacidade e tratamento de dados

O que é uma boa nota de segurança do site?

A ou A+ significa que as verificações obtiveram uma boa pontuação face à base pública avaliada por esta ferramenta no momento da análise. Notas inferiores destacam resultados a analisar e priorizar; nenhuma nota prova que a aplicação é segura.Analise os resultados individuais, confirme se se aplicam à sua implementação e verifique as correções nos percursos essenciais dos utilizadores. Uma nova execução pode confirmar a alteração testada sem certificar toda a aplicação.Guia prático de proteção de sitesOperação de WAF gerido e controlo de alterações

Como é calculada a nota de segurança do site?

A pontuação começa em 100. Cada verificação falhada desconta 25, 15, 10 ou 5 pontos consoante a severidade seja crítica, alta, média ou baixa, e cada aviso desconta 15, 10, 5 ou 2. Uma pontuação de 90 ou mais corresponde a A+, 80 a A, 65 a B, 50 a C e 35 a D; abaixo disso, a nota é F.As verificações que não foi possível concluir e os resultados informativos não alteram a pontuação. Corrija primeiro as falhas críticas e de alta severidade, porque são as que mais afetam a nota.Guia prático de proteção de sitesVerificador de Cabeçalhos de Segurança HTTP

Isto substitui um teste de penetração?

Não. Esta verificação é uma revisão rápida da postura pública. É útil para encontrar problemas comuns de configuração, mas riscos de lógica aplicacional, autenticação e processos de negócio ainda exigem testes especializados.Guia prático de proteção de sitesDiscuta o seu âmbito com a Vigilbase
Guia de Teste de Segurança Web da OWASP