A verificação que todo mundo faz (e que não resolve)
A primeira coisa que as pessoas olham é o cadeado na barra de endereço. Eu já vi gente ficar feliz com isso como se fosse uma garantia de segurança. O cadeado apenas significa que o tráfego entre você e o servidor está criptografado. Não diz nada sobre o conteúdo do site em si. Já perdi horas investigando sites de phishing que tinham HTTPS válido porque qualquer um pode gerar um certificado gratuito no Let's Encrypt em dois minutos. O problema é que a maioria dos tutoriais pela internet para como saber que um site é seguro para de recomendação aí. Eles param no cadeado e na URL começando com https://. Isso é necessário mas não suficiente. Vou te mostrar o que realmente importa depois disso, começando pela parte que ninguém olha.
Verificação de certificados SSL/TLS além do óbvio
Quando você clica no cadeado e abre as informações do certificado, a maioria das pessoas só vê se o certificado é válido e quando expira. O que eu sempre verifico é a cadeia completa de certificação. O emissor importa muito mais do que a validade em si. Sites legítimos de bancos e lojas usam certificados EV ou DV de CAs reconhecidos como DigiCert, Sectigo, Google Trust Services. Sites duvidosos às vezes aparecem com certificados de emissores pequenos que ninguém ouviu falar. Outro detalhe prático: a maioria dos navegadores modernos esconde avisos sobre mixed content. Se o site carrega imagens ou scripts via HTTP enquanto a página principal é HTTPS, o navegador vai silenciosamente deixar passar. Eu já entrei em sites que pareciam seguros e descobri que os formulários de login eram servidos via HTTP porque o desenvolvedor esqueceu de atualizar os caminhos. Você pode verificar isso manualmente abrindo o DevTools (F12), indo na aba Network e filtrando por HTTP. Se encontrar qualquer recurso sem o S, o site tem problemas de segurança reais mesmo mostrando o cadeado.
Existe também o problema dos certificados autoassinados. Se você entrar em um site e receber um aviso do navegador dizendo que o certificado é inválido ou autoassinado, fuja. Sites comerciais legítimos não usam certificados autoassinados porque isso causaria reclamações constantes dos clientes. A única exceção válida são ambientes internos corporativos com políticas de rede próprias.
Como saber que um site é seguro na prática real
Quando eu preciso avaliar se um site é confiável, meu fluxo começa pela extensão do domínio. Um site que se passa por um banco mas termina em .xyz ou .top em vez de .com.br ou .gov.br já é sinal de alerta. Não é regra absoluta mas é uma indicativo estatístico forte. Fiz essa observação depois de analisar dezenas de sites fraudulentos em projetos de segurança e notei que 90% deles usavam TLDs baratas. A idade do domínio é outro dado que a maioria ignora. Eu uso o whois.com para verificar quando o domínio foi registrado. Um site que alega ser uma instituição financeira estabelecida mas foi registrado há três semanas é imediatamente suspeito. Já caiu nesse peixe: um golpe de phishing de um famoso aplicativo de pagamento usava um domínio registrado há 11 dias com dados de quem morava em outro país. A página inteira era profissional, mas o whois entregou.
Para verificar isso rapidamente no dia a dia, você pode colar a URL em whois.domaintools.com e olhar a data de criação do registro. Sites com menos de 30 dias de existência merecem cautela extra, especialmente se pedirem dados pessoais ou financeiros.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Validação de HSTS e configurações de segurança avançadas
Uma camada extra de proteção são os headers de segurança que o servidor envia. O HSTS (HTTP Strict Transport Security) força o navegador a usar HTTPS mesmo que você tente acessar via HTTP. Se você digitar http:// de um site HSTS ativo, o navegador redireciona automaticamente para HTTPS. Para verificar se um site usa HSTS, abra o DevTools na aba Network, faça uma requisição ao site e olhe os response headers. Procure por strict-transport-security. Sites governamentais e bancários brasileiros quase sempre têm isso ativado, mas muitos sites menores não. Além do HSTS, existem outros headers relevantes: Content-Security-Policy (previne XSS), X-Frame-Options (previne clickjacking), e X-Content-Type-Options (previne MIME sniffing). Nenhum desses headers sozinho garante segurança mas a ausência deles indica falta de maturidade técnica do desenvolvedor. Já vi sites de e-commerce que processavam pagamentos sem nenhuma dessas proteções configuradas.
Configurações de segurança vs segurança real
Um ponto que ninguém menciona é a diferença entre configuração de segurança e segurança real do site. Um site pode ter SSL, HSTS, headers corretos e ainda assim ser malicioso. O cabeçalho protege a transmissão de dados, não o conteúdo entregue. Já participei de um teste de penetração onde o cliente tinha todas as configurações perfeitas mas um plugin desatualizado no WordPress permitia invasão. A camada de transporte estava segura, a aplicação estava entregue. Essa é a limitação mais importante que eu posso te dar: nenhum método visual de verificação substitui ferramenta de análise ativa. Se você precisa julgar a segurança de um site antes de inserir dados sensíveis, use o Google Transparency Report (transparencyreport.google.com/safe-browsing) ou o VirusTotal para fazer scanning da URL. Essas ferramentas cruzam múltiplas bases de dados de ameaças e são muito mais confiáveis do que qualquer verificação manual.
Um caso concreto: um colega meu entrou em um site de cupom de desconto que tinha HTTPS, domínio com dois anos de registro e parecer legítimo. Quando submeti a URL no VirusTotal, sete antivírus diferentes marcaram como phishing. Ele estava prestes a colocar o cartão de crédito. O site era sofisticado, mas a infraestrutura de hospedagem já constava em listas negras.
Verificação manual passo a passo
Aqui está o check que eu sigo antes de me cadastrar em qualquer site novo. O processo leva cerca de dois minutos e já me protegeu de várias situações: Primeiro, confirme que a URL está correta. Não confie no bookmark. Tipe o domínio manualmente ou copie da página oficial conhecida. Phishers usam domínios visualmente similares com números substituindo letras (ex: g0ogle.com em vez de google.com). Isso é chamado de homograph attack e funciona muito bem em domínios idênticos visualmente.
Segundo, verifique a idade do domínio no whois. Terceiro, abra o certificado e confirme o emitente. Quarto, rode no Google Safe Browsing ou VirusTotal. Quinto, verifique se o site aparece em reviews no Reclame Aqui ou no BBB para operações brasileiras. Sexto, analise os headers de segurança no DevTools. Se você seguir esses seis passos, a chance de cair em um golpe por site malicioso cai para praticamente zero. A maioria dos sites legítimos passa por todos eles sem dificuldade. Os que não passam são exatamente os que você quer evitar.
