Como saber se o seu site está seguro (guia prático, 2026)

Quando alguém pergunta "como tenho certeza de que meu site está seguro?", a resposta honesta é: você não tem certeza absoluta — mas consegue eliminar a maior parte do risco comum verificando cinco camadas observáveis de fora, sem instalar nada e sem acesso ao código.

Vale separar de saída o que é verificável externamente do que não é. Confundir as duas coisas é o erro mais caro: dá a sensação de aprovação sem cobrir onde os vazamentos realmente acontecem.

As 5 camadas que você verifica de fora

1. HTTPS e certificado TLS

O cadeado no navegador diz que a conexão é criptografada — e só isso. O que importa checar além dele: o certificado está perto de expirar? O site aceita protocolos antigos (TLS 1.0/1.1)? E, principalmente: http:// redireciona para https://? Um site que responde nos dois é um site onde o primeiro acesso pode ser interceptado.

2. Cabeçalhos de segurança HTTP

É a camada mais negligenciada e a mais barata de corrigir — são linhas de configuração, não refatoração. Os que mudam o jogo:

• HSTS (Strict-Transport-Security) — obriga o navegador a só falar https com o seu domínio, fechando a janela do item anterior.
• CSP (Content-Security-Policy) — a defesa central contra XSS: declara de onde script pode ser carregado. É a mais trabalhosa de acertar e a que mais protege.
• X-Frame-Options / frame-ancestors — impede que seu site seja embutido num iframe de terceiro (clickjacking).
• X-Content-Type-Options: nosniff — impede o navegador de adivinhar o tipo de um arquivo.

3. DNS

Onde mora um problema que quase ninguém procura: o subdomínio órfão. Você apontou blog.seusite.com para um serviço, cancelou o serviço e esqueceu o registro DNS. Quem registrar aquele endereço no serviço passa a servir conteúdo no seu domínio. Vale checar também DNSSEC e o registro CAA (que limita quais autoridades podem emitir certificado para você).

4. Autenticação de e-mail (SPF, DKIM, DMARC)

Não protege o site — protege o seu nome. Sem esses três registros, qualquer pessoa consegue enviar e-mail que parece vir do seu domínio. Para quem tem produto com usuários, é vetor direto de phishing contra a própria base. É configuração de DNS, resolve numa tarde.

5. Exposição acidental

Arquivos e caminhos que subiram sem querer: .env, .git/, painéis administrativos indexados, caminhos privados listados no próprio robots.txt (que é público e costuma virar um mapa do que você queria esconder).

As 2 camadas que um scan externo NÃO vê

Aqui está o limite honesto de qualquer ferramenta que olha só a URL:

• Lógica de autorização. Se o usuário A consegue ler o pedido do usuário B trocando um id na URL, isso é invisível de fora — só aparece testando com duas contas reais e permissão do dono. É a falha mais comum em apps feitos com IA, porque o gerador escreve o endpoint e esquece o "este registro é seu?".
• Segredos no código e no banco. Chave de API commitada, credencial no histórico do Git, tabela sem regra de acesso. Precisa de acesso ao repositório.

Quem promete "site 100% seguro" olhando só a URL está vendendo a primeira lista como se fosse as duas.

O caminho mais curto

Dá para fazer tudo isso à mão, uma ferramenta por camada. Ou rodar de uma vez: o scan gratuito do ecoa verifica as cinco camadas a partir da URL, sem cadastro e sem instalar nada, e devolve uma nota com os problemas por severidade.

Se você trabalha com um assistente de IA (Claude, Cursor, ChatGPT), dá para conectar o ecoa como servidor MCP e simplesmente pedir "verifique se o meu site está seguro" — a IA roda a verificação e lê o resultado dentro da conversa, sem você sair para lugar nenhum.