Como verificar a segurança do seu site: o que uma verificação passiva consegue e não consegue dizer

"O meu site é seguro?" não tem resposta de sim ou não, mas tem um primeiro passo útil: verificar as partes da sua segurança que qualquer pessoa na internet já consegue ver. Todo navegador que visita o seu site recebe a sua configuração de HTTPS, o seu certificado, os seus cabeçalhos de resposta e os seus cookies. Se eles estiverem mal configurados, você está facilitando ataques à toa, e a correção costuma ser uma mudança de configuração, não uma reescrita.

Este guia mostra o que verificar, como verificar e — tão importante quanto — o que uma verificação desse tipo não consegue dizer.

Verificações passivas versus testes de segurança

Uma verificação passiva faz o mesmo tipo de requisição que um navegador e lê as respostas. Ela nunca envia payloads de ataque, nunca envia formulários e nunca tenta fazer login. Por isso, é seguro executá-la a qualquer momento em um site no ar, e ela é boa em encontrar erros de configuração.

Um teste de invasão (pentest) é outra coisa: uma pessoa qualificada, com a sua permissão, tenta ativamente invadir — testando logins, tratamento de entradas, controle de acesso e lógica de negócio. Ele encontra as vulnerabilidades que uma verificação passiva não enxerga e não é algo para improvisar em um site em produção.

Comece pela camada passiva. É rápido, e um site que erra o básico visível normalmente tem outros problemas também.

O que verificar e como é um bom resultado

1. HTTPS em tudo, com redirecionamento permanente

Toda página deve carregar por https://, e digitar o endereço puro com http:// deve resultar em um redirecionamento 301 ou 308 para a versão HTTPS. Um 302 funciona, mas não é memorizado, e um site que ainda serve páginas por HTTP simples deixa qualquer pessoa na mesma rede lê-las ou alterá-las. Teste com curl -I http://yourdomain.com/ e observe a linha de status e o cabeçalho Location.

2. Um certificado válido que se renova sozinho

O certificado precisa ser confiável, corresponder ao seu domínio e não estar perto de expirar. Certificados expirados são quase sempre uma rotina de renovação que parou em silêncio depois de uma mudança de servidor ou de DNS. Clique no cadeado do navegador para ver o emissor e a data de validade e garanta que a renovação esteja automatizada.

3. Cabeçalhos de segurança com valores sensatos

Cabeçalhos como Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options e Referrer-Policy ativam proteções embutidas nos navegadores. Os valores importam tanto quanto a presença: um max-age de HSTS de 300 segundos que sobrou dos testes não protege quase nada, e uma CSP contendo 'unsafe-inline' ou * em script-src faz pouco contra scripts injetados. Nossos guias sobre cabeçalhos de segurança e sobre a Content-Security-Policy explicam os valores seguros.

4. Flags dos cookies

Cookies de sessão e de login devem ser Secure (somente HTTPS), HttpOnly (invisíveis para o JavaScript) e ter um valor explícito de SameSite. No navegador, abra as ferramentas do desenvolvedor e procure em Application (Chrome, Edge) ou Storage (Firefox) → Cookies. O guia sobre como verificar a segurança dos cookies explica cada flag.

5. Um CORS que não confia em todo mundo

Os cabeçalhos de Cross-Origin Resource Sharing dizem aos navegadores quais outros sites podem ler as suas respostas. O padrão arriscado é um servidor que copia qualquer Origin recebido para o Access-Control-Allow-Origin e envia Access-Control-Allow-Credentials: true. Isso permite que qualquer site leia respostas obtidas com os cookies dos seus visitantes. Libere origens específicas.

6. Nada de conteúdo misto

Uma página HTTPS que carrega scripts, folhas de estilo ou frames por http:// tem conteúdo misto ativo, que os navegadores modernos bloqueiam, muitas vezes quebrando a página. Imagens e mídias em HTTP simples são conteúdo misto passivo: menos perigoso, mas ainda assim enfraquecem o cadeado. Procure URLs com http:// fixas no código dos seus templates e no banco de dados.

7. O que você está contando aos invasores

Cabeçalhos como Server: Apache/2.4.41 ou X-Powered-By: PHP/7.4 anunciam versões exatas. Source maps de JavaScript públicos podem expor o código original do seu front-end. Nenhum dos dois é uma vulnerabilidade por si só, mas ambos poupam tempo ao invasor. Considere também publicar um arquivo /.well-known/security.txt com um Contact e uma data em Expires, para que quem encontrar um problema saiba como falar com você.

Como o verificador de segurança do Rudra faz isso

O verificador de segurança de site gratuito automatiza a lista acima. Ele envia uma requisição normal à sua página e lê os cabeçalhos, os cookies que ela define (somente nomes e flags, nunca valores) e o HTML. Depois, faz um conjunto pequeno e fixo de requisições extras somente de leitura: uma conexão TLS para o certificado, uma requisição a http://yourdomain/ para ver como ela redireciona, uma requisição com uma origem de teste inventada (https://rudra-audit.invalid) para ver como os seus cabeçalhos de CORS respondem e uma lista curta e pré-aprovada de arquivos conhecidos, como security.txt e robots.txt.

Cada achado mostra o valor observado, como seria um valor aprovado e o grau de confiança da verificação. Alguns padrões — manipuladores onclick inline ou scripts de terceiros sem Subresource Integrity — podem ser inofensivos ou arriscados conforme o contexto, por isso são sinalizados com baixa confiança para você avaliar, em vez de apresentados como problemas confirmados. O relatório também lista as tecnologias e a superfície pública que conseguiu enxergar, como formulários de login e URLs de API mencionadas na página, para você saber o que fica visível de fora.

O que uma verificação passiva não consegue dizer

É aqui que as pessoas enxergam demais em uma boa pontuação. Uma verificação passiva, a nossa incluída, não:

• encontra vulnerabilidades no seu código, como injeção de SQL, cross-site scripting ou falhas de controle de acesso;
• examina o seu CMS, plugins, bibliotecas ou servidor em busca de versões sabidamente vulneráveis (a menos que um cabeçalho acabe revelando uma versão);
• testa qualquer coisa atrás de um login, incluindo painéis administrativos e páginas de conta;
• testa como os formulários se comportam ao serem enviados, incluindo a proteção contra CSRF e a limitação de taxa (rate limiting);
• detecta malware, desfiguração (defacement) ou uma conta comprometida;
• avalia a sua hospedagem, os backups, os controles de acesso ou quem tem as senhas de administrador.

Um resultado limpo significa que a configuração visível está em boa forma. Não significa que o site seja seguro em todos os aspectos, e nenhuma varredura automatizada pode prometer isso.

O que fazer além da varredura

1. Mantenha o software atualizado. Aplique sem demora as atualizações de CMS, plugins, temas e frameworks e remova os plugins que você não usa.
2. Proteja as contas de administrador. Use senhas únicas e autenticação em dois fatores em toda conta que possa alterar o site.
3. Mantenha backups testados. Um backup que você nunca restaurou é uma esperança, não um plano.
4. Fique de olho nas mudanças. Refaça a verificação passiva depois de cada deploy e sempre que adicionar um script de terceiros.
5. Contrate um teste profissional quando o que está em jogo justificar. Se você lida com pagamentos, dados de saúde ou contas de usuários, encomende um teste de invasão a um profissional qualificado, com um escopo definido por escrito.

Para o restante da saúde do seu site — velocidade, SEO, acessibilidade e links quebrados — faça uma auditoria de site completa na mesma página.