Rudra Analyzer

Verificador de segurança de site gratuito

Verifique como seu site protege os visitantes: HTTPS e o redirecionamento de http→https, o certificado SSL/TLS, os valores dos seus cabeçalhos de segurança, os atributos dos cookies, CORS e conteúdo misto. É uma verificação de configuração passiva e somente leitura, que envia apenas requisições GET e HEAD normais — não é um teste de invasão.

Digite uma página, por exemplo https://seusite.com.br ou https://seusite.com.br/precos.

O que esta ferramenta verifica

  • HTTPS e redirecionamentos

    Se a página termina em https:// após os redirecionamentos, as etapas no caminho e se http://seudominio/ responde com um redirecionamento permanente (301 ou 308) para HTTPS.

  • Certificado SSL/TLS

    Se o certificado é confiável e corresponde ao seu domínio, qual versão do TLS é usada, quem o emitiu e quantos dias faltam para vencer.

  • Valor do HSTS

    O cabeçalho Strict-Transport-Security é interpretado, não apenas detectado: um max-age de pelo menos 180 dias, nenhuma diretiva malformada, includeSubDomains e se um sinalizador preload é respaldado pelas configurações que a lista de preload exige.

  • Diretivas de Content-Security-Policy

    Cada diretiva é lida: se os scripts são restringidos, 'unsafe-inline' (não sinalizado quando um nonce ou hash é usado), 'unsafe-eval', fontes amplas como *, https: ou data: em script-src, object-src, base-uri, e se a política é apenas Report-Only.

  • Proteção contra clickjacking

    X-Frame-Options (incluindo valores inválidos e o obsoleto ALLOW-FROM), ou uma regra CSP frame-ancestors que não seja * nem apenas um esquema.

  • Outros cabeçalhos de proteção

    X-Content-Type-Options deve ser exatamente nosniff; Referrer-Policy é verificado quanto a unsafe-url e valores não reconhecidos; Permissions-Policy quanto a recursos deixados abertos. Os cabeçalhos de isolamento entre origens são listados como informação.

  • Exposição de versões e source maps

    Cabeçalhos Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version e X-Generator que revelam números de versão, e source maps públicos de até três dos seus próprios scripts.

  • Atributos dos cookies

    Cookies definidos pela resposta da página, apenas pelo nome: Secure em HTTPS, HttpOnly em cookies cujos nomes sugerem sessão ou token, SameSite=None sem Secure, ausência de SameSite e cookies com escopo em um domínio pai.

  • CORS

    Uma requisição extra com uma Origin inofensiva e inventada (https://rudra-audit.invalid) para ver se seu servidor devolve qualquer origem — e se também permite credenciais, que é a combinação arriscada.

  • Conteúdo misto

    Scripts, folhas de estilo ou frames http:// em uma página HTTPS (conteúdo misto ativo) e imagens ou mídia http:// (passivo).

  • security.txt

    Se /.well-known/security.txt existe e tem uma linha Contact e uma data Expires no futuro, para que pesquisadores saibam como entrar em contato com você.

  • Tecnologias e superfície visível

    Frameworks e serviços reconhecíveis pelos cabeçalhos e pelo HTML, além de formulários de login, URLs de API ou de documentação mencionadas na página e arquivos públicos como robots.txt. Listados para conhecimento; não custam pontos.

  • Padrões no lado do cliente (revisão manual)

    Manipuladores de eventos inline como onclick e scripts de terceiros carregados sem Subresource Integrity. São dicas de baixa prioridade para revisar, não vulnerabilidades confirmadas.

Como a verificação funciona

Enviamos uma requisição GET normal à sua página, seguimos os redirecionamentos e lemos a resposta: valores dos cabeçalhos, os cookies que ela define (apenas nomes e atributos) e o HTML. Junto com ela, fazemos um conjunto pequeno e fixo de requisições somente leitura: uma conexão TLS para validar o certificado, um GET com uma Origin de teste inofensiva para CORS, uma requisição para http://seudominio/ para ver como redireciona, os arquivos permitidos /.well-known/security.txt, robots.txt, sitemap.xml, humans.txt e o manifest ao qual sua página aponta e — para até três dos seus próprios scripts — o final do arquivo e uma requisição HEAD para o source map que ele menciona.

Nada é enviado por formulário, nenhuma credencial é enviada, nenhum payload de ataque é usado e nenhum caminho é adivinhado. Requisições para endereços de rede privados ou internos são bloqueadas. Se a página responder com um erro de servidor (5xx), não analisamos os cabeçalhos dela, porque páginas de erro costumam ser diferentes do site real; essas verificações são marcadas como não executadas, e não como reprovadas.

A pontuação começa em 100 e cada desconto é listado no relatório. Não usar HTTPS custa 40 pontos, um certificado inválido ou expirado 40, uma falha na conexão TLS 30, CORS que confia em qualquer origem com credenciais 25, a falta do cabeçalho HSTS 15 e a falta de CSP 12. Configurações mais fracas custam menos — por exemplo, sem redirecionamento de http→https 10, conteúdo misto ativo 8, uma CSP apenas Report-Only 8, scripts 'unsafe-inline' 6, cookies sem Secure 6 e um max-age do HSTS curto 5. Muitos resultados informativos, como a ausência de security.txt, não custam nada, e o mesmo problema nunca é descontado duas vezes.

As evidências que você verá

Cada cabeçalho é mostrado com o valor real e uma avaliação simples (bom, fraco ou ausente); os resultados de CSP incluem a tabela de diretivas interpretadas; os resultados de cookies listam os nomes dos cookies e seus atributos, nunca os valores; o resultado de CORS mostra a origem de teste e o que voltou. Cada resultado informa o que esperávamos, a URL a que se aplica, o grau de confiança da verificação e a fonte — a resposta HTTP, o HTML ou a conexão TLS.

O que esta ferramenta não verifica

  • Não é um teste de invasão

    Sem exploração, sem payloads de ataque, sem força bruta e sem adivinhar caminhos ocultos. Ela lê a configuração que qualquer navegador recebe.

  • Páginas que exigem login

    Nunca fazemos login nem enviamos credenciais, então páginas autenticadas, áreas administrativas e configurações de conta não são testadas.

  • Seu código e suas dependências

    Sem revisão de código do servidor e sem busca de vulnerabilidades no seu CMS, plugins, bibliotecas ou software do servidor.

  • Malware ou site comprometido

    Ela não procura malware, desfiguração, injeção de spam nem contas vazadas.

  • Todos os cookies que seu site usa

    Só são vistos os cookies definidos pela própria resposta da página — não os adicionados depois por JavaScript, por outras páginas ou por terceiros. Os valores dos cookies nunca são lidos.

  • Como seus formulários se comportam

    Os formulários são registrados, mas nunca enviados, então a validação do lado do servidor, a proteção contra CSRF e a limitação de requisições não podem ser testadas.

Problemas comuns que encontramos

  • HSTS ausente ou curto demais

    Muito comum, mesmo em sites que redirecionam tudo para HTTPS — e um max-age de poucos minutos, que sobrou dos testes, quase não oferece proteção.

  • Sem CSP, ou uma que permite demais

    O cabeçalho ausente com mais frequência. Quando está presente, 'unsafe-inline', 'unsafe-eval' ou um * em script-src muitas vezes anulam a maior parte da proteção.

  • Sem proteção contra clickjacking

    Nem X-Frame-Options nem uma regra frame-ancestors.

  • Certificados perto do vencimento

    Geralmente porque a renovação automática parou de funcionar depois de uma mudança de servidor ou de DNS.

  • Versão do servidor à mostra

    Cabeçalhos como “Server: Apache/2.4.41” ou “X-Powered-By: PHP/7.4” que dizem aos invasores o que procurar.

  • HTTP que não redireciona

    http://seudominio/ ainda serve páginas, ou redireciona apenas temporariamente (302), então visitantes que digitam só o domínio podem navegar sem criptografia.

  • Cookies de sessão sem Secure ou HttpOnly

    Cookies de login ou de sessão que scripts conseguem ler, ou que podem ser enviados por HTTP comum.

Como corrigi-los

  1. Configure os cabeçalhos onde seu site é servido

    Os cabeçalhos são configurados no seu servidor web (add_header no Nginx, Header set no Apache), na sua CDN ou nas configurações ou no arquivo de cabeçalhos da sua hospedagem. Execute a verificação de novo para confirmar o valor que realmente chega aos navegadores.

  2. Ative o HSTS quando o HTTPS funcionar em todo lugar

    Use Strict-Transport-Security: max-age=31536000 (180 dias é o mínimo que aceitamos). Adicione includeSubDomains apenas quando todos os subdomínios aceitarem HTTPS, e preload por último.

  3. Reforce a CSP aos poucos

    Comece com Content-Security-Policy-Report-Only e depois aplique a política. Substitua 'unsafe-inline' por nonces ou hashes, remova 'unsafe-eval', liste as origens exatas dos scripts em vez de * ou https: e adicione object-src 'none' e base-uri 'self'.

  4. Adicione os cabeçalhos simples

    X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin e X-Frame-Options: DENY (ou SAMEORIGIN) raramente quebram alguma coisa.

  5. Automatize a renovação do certificado e os redirecionamentos

    Use certificados gerenciados ou o Let's Encrypt com renovação automática, e redirecione cada requisição http:// com um 301 ou 308 para a mesma URL https://.

  6. Oculte os números de versão

    Desative os indicadores de versão (por exemplo, server_tokens off no Nginx, expose_php = Off no PHP) e não publique source maps em produção, a menos que seja intencional.

  7. Configure os atributos dos seus cookies

    Dê a todos os cookies o atributo Secure em um site HTTPS, adicione HttpOnly aos cookies de sessão e de login e defina SameSite=Lax (ou Strict) explicitamente. SameSite=None sempre precisa de Secure.

Perguntas frequentes

Isto é um teste de invasão ou uma varredura de vulnerabilidades?

Não. Ela lê a configuração que qualquer navegador recebe — HTTPS, o certificado, valores de cabeçalhos, atributos dos cookies, CORS — usando apenas requisições GET e HEAD normais. Ela não tenta encontrar nem explorar vulnerabilidades. Para isso, contrate um profissional de testes de segurança qualificado e dê a ele autorização por escrito.

Ele consegue dizer se meu site foi hackeado?

Não. Ela não procura malware, páginas desfiguradas ou contas comprometidas. Uma boa pontuação significa que as partes visíveis da segurança de transporte e do navegador estão bem configuradas — não que o site seja seguro em todos os aspectos.

Ele avalia a qualidade dos meus cabeçalhos?

Sim, para os principais. O HSTS é verificado quanto a um max-age de pelo menos 180 dias e diretivas malformadas; a CSP é interpretada diretiva por diretiva em busca de 'unsafe-inline', 'unsafe-eval', fontes de script amplas e ausência de object-src ou base-uri; os valores de X-Frame-Options, X-Content-Type-Options e Referrer-Policy também são validados.

Por que o HSTS não é verificado no meu site em HTTP?

O HSTS só tem efeito em HTTPS. Se seu site não está em HTTPS, esse é o problema maior, e é ele que aparece no relatório.

Adicionar cabeçalhos de segurança pode quebrar meu site?

A maioria dos cabeçalhos pode ser adicionada com segurança. Uma Content-Security-Policy pode bloquear scripts, estilos ou conteúdos incorporados de que seu site depende, então teste-a primeiro no modo report-only. Adicionar Secure ou SameSite aos cookies pode afetar logins que envolvem vários domínios, então teste o login depois.

A verificação de CORS é segura para o meu site?

Sim. É uma única requisição GET comum com um cabeçalho Origin de um domínio que não pode existir (rudra-audit.invalid). Nenhum cookie ou credencial é enviado e nada é alterado; apenas lemos quais cabeçalhos CORS voltam.

Por que alguns resultados estão marcados como precisando de revisão manual?

Padrões como manipuladores onclick inline ou scripts sem Subresource Integrity podem ser aceitáveis ou arriscados, dependendo do contexto. Nós os sinalizamos com baixa confiança para que você decida, em vez de apresentá-los como problemas confirmados.

Guias úteis

Ferramentas gratuitas relacionadas

Prefere que alguém corrija por você?

Estas verificações são gratuitas, assim como os guias. Se preferir que uma pessoa faça as mudanças, nossa equipe oferece ajuda paga.

Ver opções de ajuda profissionalComo testamos e pontuamosTodas as ferramentas gratuitas