HTTP vs HTTPS: por que o navegador mostra 'não seguro'

Você digita o endereço de um site e o navegador mostra "Não seguro" ao lado dele. Na maioria das vezes a causa é simples: o site foi aberto por http:// em vez de https://. A diferença é uma letra no endereço, mas muda quem consegue ler o que trafega entre você e o servidor.

Os navegadores ficaram cada vez mais insistentes com esse aviso, e um site só em HTTP perde visitantes. Migrar um site ou API para HTTPS sem quebrar links, cookies nem imagens leva quatro passos, descritos mais abaixo.

Qual é a diferença entre HTTP e HTTPS?#

HTTP é o protocolo que define como navegador e servidor trocam requisições e respostas. Ele não criptografa nada: URL, cabeçalhos, cookies e corpo da resposta viajam em texto aberto. HTTPS é o mesmo HTTP, só que dentro de uma conexão protegida por TLS. A aplicação continua falando HTTP; o TLS cuida de cifrar, detectar alterações e provar a identidade do servidor.

Os navegadores só usam HTTP/2 e HTTP/3 sobre TLS. Na prática, HTTPS costuma ser tão rápido quanto HTTP, e muitas vezes mais.

Por que o navegador mostra "não seguro"?#

Porque numa conexão HTTP qualquer equipamento no caminho vê e pode alterar a página: o Wi-Fi do café, o roteador do hotel, o provedor de internet. Isso permite roubar um cookie de sessão, trocar um link de download ou injetar anúncios e scripts na sua página sem você saber.

O Google anunciou, em outubro de 2025, que o Chrome 154 passaria a ativar por padrão a opção "Always Use Secure Connections" para sites públicos. Com a opção ligada, o Chrome pede permissão ao usuário antes da primeira visita a um site público sem HTTPS. O aviso não se repete para sites que a pessoa visita com frequência, e endereços privados (IPs locais e hostnames de intranet) ficam de fora. O usuário ainda pode desligar a configuração. Na prática, um site só em HTTP espanta visitantes novos antes mesmo de carregar.

O que HTTPS protege e o que não protege?#

Protege três coisas em trânsito:

• Confidencialidade: quem intercepta vê bytes sem sentido, incluindo o caminho da URL e os cabeçalhos.
• Integridade: qualquer alteração no meio do caminho é detectada.
• Autenticação: o certificado confirma que você está falando com o servidor daquele domínio.

Não protege o que acontece fora da conexão. HTTPS não corrige SQL injection, senha fraca ou um servidor invadido, e o cadeado não prova que o site é honesto: um site de golpe também pode ter certificado válido. O nome do domínio e o IP de destino geralmente continuam visíveis para quem observa a rede.

Como migrar um site de HTTP para HTTPS?#

A migração tem quatro passos, nesta ordem.

1. Tenha um certificado válido para o domínio. Autoridades como o Let's Encrypt emitem certificados DV sem custo, e a renovação é automática na maior parte das plataformas.
2. Redirecione todo HTTP para HTTPS com um redirecionamento permanente (301 ou 308).
3. Ative o HSTS depois de confirmar que o HTTPS funciona.
4. Corrija o conteúdo misto, explicado mais abaixo.

Um exemplo em Node.js com Express 5, atrás de um proxy que termina o TLS (o caso mais comum em hospedagem):

import express from "express";

const app = express();
const HOST = process.env.PUBLIC_HOST ?? "example.com"; // seu domínio canônico

// Confia no primeiro proxy para ler X-Forwarded-Proto
app.set("trust proxy", 1);

app.use((req, res, next) => {
  if (!req.secure) {
    // Host fixo: nunca monte o redirecionamento a partir de um cabeçalho que o cliente controla
    return res.redirect(308, `https://${HOST}${req.originalUrl}`);
  }
  // 1 ano; só enviado em respostas HTTPS
  res.set("Strict-Transport-Security", "max-age=31536000");
  next();
});

app.get("/", (req, res) => res.send("Olá por HTTPS"));

app.listen(process.env.PORT || 3000);

Sem trust proxy, o app vê a conexão local do proxy (HTTP puro) e req.secure fica sempre falso, o que gera um loop de redirecionamento. Entenda o motivo em proxy reverso. O redirecionamento usa um domínio fixo porque, com trust proxy ligado, o req.hostname vem do cabeçalho X-Forwarded-Host, e montar a URL a partir dele poderia mandar o visitante para outro site.

Confira o resultado com o curl:

curl -sI http://example.com | head -n 3
curl -sI https://example.com | grep -i strict-transport-security

O primeiro comando deve mostrar um redirecionamento para https://, e o segundo, o cabeçalho HSTS.

O que é HSTS e quando ativar?#

HSTS (HTTP Strict Transport Security) é um cabeçalho que diz ao navegador: "este host só deve ser acessado por HTTPS". Depois de recebê-lo, o navegador converte sozinho qualquer http:// para https:// durante o prazo max-age, em segundos, e o usuário não consegue ignorar erros de certificado. Isso fecha a brecha da primeira requisição em HTTP, que o redirecionamento sozinho deixa aberta.

Strict-Transport-Security: max-age=31536000; includeSubDomains

O navegador ignora o cabeçalho em respostas HTTP, então ele só vale quando enviado por HTTPS. Para entrar na lista de preload dos navegadores, o domínio precisa de max-age de pelo menos 31536000 (1 ano), includeSubDomains e preload, e o envio é feito em hstspreload.org.

Cuidado: includeSubDomains obriga todos os subdomínios a ter HTTPS funcionando. Comece com um max-age curto (por exemplo, 300) e aumente aos poucos. Sair da lista de preload depois é lento, porque depende de novas versões dos navegadores.

O que é conteúdo misto e como corrigir?#

Conteúdo misto acontece quando uma página carregada por HTTPS pede recursos por http://. É a causa mais comum de um site com certificado válido ainda parecer quebrado.

Os navegadores tratam dois grupos de forma diferente. Imagens, vídeo e áudio são atualizados automaticamente para HTTPS. Todo o resto, como scripts, folhas de estilo, iframes, fetch() e fontes, é bloqueado. Se o host do recurso for um IP em vez de um nome de domínio, até a imagem é bloqueada.

Para corrigir:

• Troque http:// por https:// nos seus templates, ou use URLs relativas para recursos do próprio site.
• Atualize URLs salvas no banco (conteúdo de blog, campos de imagem).
• Confirme que o recurso externo existe em HTTPS: trocar só o esquema não adianta se o servidor de destino não responde por TLS.
• Como rede de segurança, o cabeçalho Content-Security-Policy: upgrade-insecure-requests pede ao navegador que reescreva todas as requisições para HTTPS.

O console do navegador (aba Console, nas ferramentas de desenvolvedor) lista cada recurso bloqueado ou atualizado. Se o aviso persistir mesmo sem conteúdo misto, o problema pode ser o certificado: veja erros de certificado SSL.

Quando HTTP puro ainda é aceitável?#

Em desenvolvimento local (http://localhost) e em redes internas privadas, HTTP é comum e o Chrome não aplica o aviso a endereços privados. Em qualquer serviço acessível pela internet pública, o padrão é HTTPS, inclusive para APIs, webhooks e painéis: webhook de bots, por exemplo, costuma exigir uma URL HTTPS.

Como fazer isso na Square Cloud#

Toda aplicação web na Square Cloud ganha um subdomínio *.squareweb.app com HTTPS em todos os planos. O TLS é automático: um certificado DV é emitido e renovado sozinho, então você não gera nem renova certificados.

Para usar seu próprio domínio (a partir do plano Standard), você cria no seu registrador os registros DNS que o painel mostra e acompanha o status de validação em tempo real. O TLS é provisionado automaticamente, e o domínio continua registrado em seu nome no seu registrador.

A rede inclui CDN Anycast, HTTP/3 e WAF, e redireciona HTTP para HTTPS. Os cabeçalhos da sua aplicação, como o HSTS, passam intactos e continuam sob seu controle no código. Veja o passo a passo em domínios personalizados, o comportamento da rede em rede e CDN e, para vários apps no mesmo domínio, load balancing.