Como funciona esta verificação
O Scanaris analisa o HTML da tua página principal e procura formulários que contenham um campo <input type="password">: um login, um registo, uma mudança de palavra-passe. Se não houver nenhum, não faz nada. Se houver, verifica duas coisas. Primeira: se a própria página foi servida por HTTP, abre um achado de severidade alta, porque tudo o que o utilizador escrever viaja sem cifrar. Segunda: se a página é HTTPS mas o atributo action do formulário começa por http://, abre outro achado de severidade alta com esse URL, porque o envio concreto da palavra-passe sai sem cifrar mesmo que a página que a pede fosse segura. Só se revê a página analisada; se o teu login vive noutra rota, analisa-a diretamente.
Porque importa
Uma palavra-passe é o dado mais valioso que um utilizador te entrega, e é o que as ligações sem cifra tratam pior. Quando um formulário viaja por HTTP, qualquer pessoa no caminho (o wifi de um café, o fornecedor de acesso, um router comprometido) pode ler o utilizador e a palavra-passe tal e qual, sem técnica nenhuma. E como a maioria das pessoas reutiliza palavras-passe, o que foge não é só o acesso ao teu site. Os browsers sabem-no: o Chrome e o Firefox marcam a vermelho qualquer campo de palavra-passe numa página HTTP e avisam o utilizador de que "não é seguro", por isso além de um risco real é uma perda de confiança visível.
Porque acontece
O primeiro caso aparece quando o site não redireciona de HTTP para HTTPS e alguém chega por uma ligação antiga. O segundo é quase sempre um action escrito à mão durante o desenvolvimento (http://localhost:3000/login ou http://api.meudominio.com/auth) que ninguém mudou, ou um formulário copiado de um exemplo. Também ocorre quando o login aponta para um serviço externo que ainda não tem certificado.
Como corrigir
- Serve todo o site por HTTPS e redireciona HTTP. É a base de tudo o resto; a verificação de redirecionamento HTTPS diz-te se o tens. No Vercel, Netlify ou Cloudflare vem feito; no teu próprio servidor, um bloco de redirecionamento no nginx ou Apache.
- Muda o action para um caminho relativo (
action="/login"), que herda o protocolo da página, ou para o URL completo comhttps://. Se usas uma framework (Nuxt, Next.js, Laravel, Django), o URL da API deve vir de uma variável de ambiente com o valor de produção, não estar escrito no template. - Se o login é gerido por terceiros (Auth0, Supabase, Firebase, Clerk), o endpoint deles já é HTTPS; o achado aponta então para um
actionteu que está a mais. - Adiciona HSTS para que o browser não volte a tentar HTTP nem no primeiro salto; mede-o HSTS fraco.
Confirma que está corrigido
curl -sI http://teudominio.com/login | grep -iE "^(HTTP|location)"
curl -s https://teudominio.com/login | grep -oE '<form[^>]*action="[^"]*"' O primeiro deve devolver um 301 para https://. No segundo, nenhum action pode começar por http://; o normal é ver caminhos relativos ou nada (os formulários sem action enviam para a própria página).
Perguntas frequentes
O meu formulário envia por JavaScript, não por action. Afeta-me?
Esta verificação olha para o atributo action, por isso um formulário que faz fetch não é marcado por essa via. Mas o risco é o mesmo se o fetch apontar para http://: numa página HTTPS o browser bloqueia-o como conteúdo misto, e numa página HTTP viaja em claro. Revê o URL da API de qualquer forma.
É só um ambiente de testes sem utilizadores reais.
Então não o analises como se fosse produção, ou aceita o achado. Mas cuidado com os ambientes de testes que acabam no Google: se alguém criar lá uma conta com a sua palavra-passe habitual, o problema é real.
Um campo de palavra-passe numa página HTTPS com action relativo está bem?
Sim. É a configuração correta e não gera achado. O que falta ver é como guardas depois a sessão: cookies inseguros e token no armazenamento cobrem essa parte.