Como saber se o teu site é seguro em 5 minutos

Não precisas de ser especialista em segurança para saber se o teu site tem as falhas mais comuns. Com um navegador, um terminal e cinco minutos podes verificar o que um atacante automatizado testa nos primeiros segundos: se o tráfego vai cifrado, se faltam cabeçalhos, se há chaves no código, se a tua API aceita pedidos de qualquer sítio e se há ficheiros que não deviam estar lá. Este guia leva-te passo a passo, com o comando exato, o que significa cada resultado e o que fazer consoante o que encontrares. No fim tens como priorizar e que coisas este teste não deteta.

Minuto 1: HTTPS e redirecionamento

Escreve o teu domínio com http:// à frente, sem o s. Deve levar-te à versão https:// de imediato. No terminal:

curl -sI http://oteudominio.com | head -3
curl -sI http://oteudominio.com/precos | head -3

As duas respostas devem ser um 301 com Location: https://.... Se a segunda não redirecionar, o teu redirecionamento só cobre a home. Depois, com https://, vê se aparece o cabeçalho Strict-Transport-Security: diz ao navegador para não voltar a usar HTTP. Se estás na Vercel, na Netlify ou na Cloudflare, o redirecionamento já vem posto e o HSTS tens de o acrescentar tu. O que significa cada detalhe do certificado, em o que significa realmente a tua nota de TLS.

Minuto 2: cabeçalhos de segurança

curl -sI https://oteudominio.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Deviam sair pelo menos cinco linhas. Cada uma que falte é uma proteção que o navegador não pode aplicar: sem X-Frame-Options o teu site pode ser embutido noutro para enganar os teus utilizadores; sem X-Content-Type-Options o navegador adivinha tipos de ficheiro; sem Content-Security-Policy qualquer script injetado executa-se sem travão. Se não gostas do terminal, cola o teu URL no analisador de cabeçalhos. O significado de cada um, em cabeçalhos HTTP explicados para humanos.

Minuto 3: segredos no JavaScript

Abre o teu site, clique direito, "Ver código-fonte". Procura .js para ver que ficheiros de script carrega, abre o principal e usa a pesquisa do navegador com estes termos:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

No terminal podes fazê-lo de uma vez sobre todos os scripts da home:

curl -s https://oteudominio.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://oteudominio.com$s";; *) u="https://oteudominio.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Há coisas que é normal encontrar: a chave pública do Stripe (pk_live), a chave anon do Supabase ou a configuração do Firebase foram desenhadas para ir no navegador. O que nunca deve aparecer: sk_live, service_role, chaves da AWS (AKIA), tokens da OpenAI ou qualquer coisa que se chame secret. Se encontrares uma, dá-a por comprometida e roda-a antes de a tirares do código. A lista completa está em segredos que a tua app deixa fugir no navegador.

Minuto 4: CORS e cookies

O CORS decide que outros sites podem fazer pedidos à tua API a partir do navegador. Pede um endpoint teu a fingir que vens de outro domínio:

curl -sI -H "Origin: https://evil.example" https://oteudominio.com/api/me | grep -i "access-control"

Se responder Access-Control-Allow-Origin: https://evil.example ou * juntamente com Access-Control-Allow-Credentials: true, qualquer site pode ler dados dos teus utilizadores com a sessão deles. A origem permitida deve ser a tua e só a tua. Já que estás aí, olha para as cookies na resposta de login ou nas ferramentas do navegador: as de sessão precisam de Secure, HttpOnly e SameSite=Lax ou Strict. O detalhe em CORS mal configurado.

Minuto 5: ficheiros expostos

As ferramentas e os deploys a meio deixam rastos. Testa estes caminhos e vê que código devolvem:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://oteudominio.com/$p"
done

O que queres ver é 404 (ou 301 para a tua página de erro). Um 200 em .env ou .git/config é grave: o primeiro contém as tuas credenciais e o segundo permite descarregar o código-fonte completo. Um 200 em swagger.json ou api/debug não é uma fuga em si, mas dá a um atacante o mapa da tua API.

Minuto extra: o que os bots veem

Se te sobrar um minuto, vê o /robots.txt e o /sitemap.xml: que existam, que não bloqueiem toda a gente e que o sitemap tenha só páginas que queres indexar. Não é segurança em sentido estrito, mas um Disallow: / esquecido da fase de testes custa meses de posicionamento.

Como priorizar o que encontrares

Nem tudo pesa o mesmo. Esta é a ordem que usamos:

Crítico, hoje mesmo. Uma chave secreta no JavaScript; .env ou .git acessíveis; uma API que aceita qualquer origem com credenciais. Roda, apaga, fecha. Depois revê se alguém o usou.
Alto, esta semana. Sem redirecionamento para HTTPS; cookies de sessão sem HttpOnly ou Secure; rotas de depuração em produção.
Médio, este mês. Cabeçalhos em falta; sem HSTS; certificado a expirar em breve sem renovação automática.
Baixo. Documentação de API exposta, robots.txt e sitemap descuidados, cabeçalhos que revelam a versão do servidor.

O que estes cinco minutos não detetam

Sê honesto com os limites. Este teste olha para a superfície que qualquer pessoa pode ver de fora. Não verifica se a tua base de dados deixa ler linhas de outros utilizadores (no Supabase é o RLS, no Firebase são as regras), se as tuas dependências têm vulnerabilidades conhecidas, se a tua lógica de negócio permite saltar um pagamento ou se um formulário aceita qualquer entrada. Para o primeiro, o guia de Supabase e o de Firebase explicam como testar. Para o resto é preciso olhar para o código, e a checklist antes de lançar reúne o essencial.

O Scanaris faz isto e mais quarenta coisas em 30 segundos

Os cinco passos acima são o núcleo do que o Scanaris verifica, mais cerca de quarenta testes que não cabem em cinco minutos: cada cabeçalho em separado, os segredos com padrões de dezenas de serviços, os ficheiros expostos com uma lista muito mais longa, TLS completo, cookies, CORS em várias rotas, e ainda o estado do teu SEO e da tua visibilidade para a IA. Por cada falha dá-te um fix prompt para colar no Lovable, no Bolt, no Cursor ou no v0 com a alteração exata, e pode repetir a análise todos os dias e avisar-te se algo piorar. São tudo verificações só de leitura sobre o que já é público no teu site.

Perguntas frequentes

É legal analisar o meu próprio site assim?

Sim. Tudo o que está aqui são pedidos normais que qualquer navegador faz; estás apenas a ler o que o teu servidor já responde a qualquer pessoa. Fá-lo apenas em domínios teus ou com autorização.

E se não sei usar o terminal?

Os passos 1, 3 e 5 podem fazer-se a partir do navegador (escrever URLs e ver o código-fonte), o 2 com o analisador de cabeçalhos gratuito, e o 4 é o único que precisa dele. Ou deixa que um scanner o faça por ti.

De quanto em quanto tempo devo repetir?

Sempre que fizeres deploy de algo relevante e, no mínimo, uma vez por mês. As apps feitas com IA mudam depressa, e uma regeneração de código pode voltar a introduzir uma falha que já tinhas corrigido.