Defaults.Exposed › Correções › HSTS (Strict-Transport-Security)

Como corrigir HSTS (Strict-Transport-Security)

O HSTS é uma instrução de uma linha que o seu site dá a cada navegador: «volta sempre a mim pela ligação segura e encriptada — nunca pela insegura». Sem ele, o seu cadeado pode ser silenciosamente retirado numa Wi-Fi partilhada, e a primeira visita ao seu site fica exposta.

O essencial para o seu negócio: Ter HTTPS (o cadeado) não é o mesmo que impô-lo. Sem HSTS, um atacante na mesma Wi-Fi que o seu cliente pode descer a ligação em silêncio para HTTP simples e não encriptado — capturando logins, dados de cartão e dados de formulário enquanto o cliente não vê nada de errado. O seu certificado SSL, que pode estar a pagar, é contornado. A correção é gratuita e leva cerca de 15 minutos a quem gere o seu site.

Quanto isto lhe pode custar

• Clientes em Wi-Fi de café, hotel, aeroporto ou conferência podem ter a ligação ao seu site descida em silêncio e os dados lidos — sem aviso no ecrã.
• Pagou por HTTPS e tem o cadeado, mas sem HSTS os atacantes podem simplesmente contorná-lo; o certificado dá uma falsa sensação de segurança.
• A primeira visita ao seu site (antes de qualquer redirecionamento para HTTPS) é o ponto fraco que os atacantes visam — o HSTS é o que o fecha em cada visita de regresso.
• Um questionário de segurança, formulário de ciberseguro ou lista de verificação de comprador empresarial sinaliza «sem HSTS» e estagna o negócio até ser corrigido.
• Define o valor errado (demasiado curto) e fica com o pior de dois mundos: parece configurado mas dá quase nenhuma proteção real.

Por que importa. O HTTPS protege uma ligação uma vez encriptada — mas não força os navegadores a usá-la. Os atacantes exploram essa brecha com «SSL stripping»: em qualquer rede partilhada mantêm o visitante em silêncio em HTTP inseguro, lendo tudo. O HSTS diz ao navegador para recusar HTTP simples para o seu domínio por completo, durante muito tempo, de modo a que a brecha se feche após a primeira visita. É um único cabeçalho de resposta, gratuito de adicionar, e na nossa pontuação vale pontos reais porque um valor em falta ou demasiado curto deixa cada visitante em Wi-Fi pública exposto.

O que é isto, em palavras simples

Quase de certeza que tem HTTPS — o pequeno cadeado na barra do navegador. Ótimo. Mas eis a parte que quase ninguém é avisado: ter HTTPS não é o mesmo que forçá-lo.

O HTTPS torna uma ligação encriptada uma vez que o navegador decide usá-la. O HSTS — abreviatura de HTTP Strict Transport Security — é a instrução que faz o navegador usá-la sempre. É uma única linha invisível que o seu site envia a cada visitante e que diz, na prática:

«A partir de agora, para o meu domínio, fala comigo só pela ligação segura. Nunca pela insegura. Nem tentes.»

O navegador lembra-se disso e obedece pelo tempo que lhe disser — tipicamente um ano. Após a primeira visita segura de um visitante, o navegador dele vai simplesmente recusar carregar o seu site por HTTP simples e não encriptado, mesmo que algo tente forçá-lo.

Sem HSTS, essa regra de «usar sempre a versão segura» não existe — e os atacantes sabem exatamente como explorar a brecha.

Quanto isto lhe pode custar

Estes são cenários realistas e do dia a dia. Nunca nomeamos uma empresa real; são ilustrações de como a brecha é usada.

1. O checkout no café. Um cliente abre a sua loja na Wi-Fi do café e vai finalizar a compra. Um atacante na mesma rede corre uma ferramenta gratuita e bem conhecida que mantém o cliente em HTTP simples em vez de HTTPS. O cliente vê o que parece o seu site normal — sem aviso, sem cadeado partido no sítio onde olharia — e escreve os dados do cartão. O atacante lê cada tecla. O seu certificado SSL não fez nada, porque a ligação nunca foi autorizada a tornar-se segura, em primeiro lugar.

2. O funcionário em viagem. Um colaborador inicia sessão no seu painel de administração ou webmail a partir de um hotel ou aeroporto. O mesmo truque de descida captura o nome de utilizador e a palavra-passe. Agora o atacante tem uma via para dentro do seu negócio — não porque a sua política de palavras-passe era fraca, mas porque a página de login era alcançável por HTTP inseguro.

3. O negócio que estagna. Um cliente maior envia-lhe o seu questionário de segurança padrão antes de assinar. Uma linha pergunta: «O seu site impõe HTTPS via HSTS?» O seu contacto de TI tem de responder «não», e o processo de compras pausa enquanto se apressam a corrigir uma definição gratuita de 15 minutos que agora parece um sinal vermelho à frente de um comprador.

4. A verificação de ciberseguro ou conformidade. A análise de uma seguradora, ou um auditor a rever a sua postura de proteção de dados, sinaliza o cabeçalho em falta. A encriptação de dados pessoais é uma expectativa explícita sob as regras de proteção de dados (Artigo 32.º do RGPD), e «temos um certificado mas não o impomos» é um lugar fraco onde estar.

5. A falsa sensação de segurança. Está a pagar por SSL, o cadeado aparece, e todos assumem que o site é seguro. Maioritariamente é — até um cliente estar numa rede partilhada, que é exatamente quando está mais vulnerável e menos propenso a reparar em algo errado.

O fio comum: o custo não é abstrato. É o cartão ou o login de um cliente real, capturado no pior momento possível, sem nenhum alarme a tocar.

O que é na realidade

Quando um navegador pede uma página ao seu site, o seu servidor devolve a página mais alguns «cabeçalhos» invisíveis — instruções extra que o navegador lê mas o visitante nunca vê. O HSTS é um desses cabeçalhos:

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

Três partes importam:

• max-age — quanto tempo (em segundos) o navegador deve lembrar-se de forçar HTTPS. 31536000 é um ano. É o cerne disto: demasiado curto e mal ajuda.
• includeSubDomains — estende a regra a todos os subdomínios (loja., app., mail. e assim por diante), não só ao seu endereço principal.
• preload — inscreve o seu domínio numa lista mestre integrada nos navegadores, para que a proteção se aplique mesmo no primeiríssimo pedido de um visitante, antes de ele ter visto o seu site alguma vez.

Porque importa «a primeira visita»

O HSTS tem uma limitação inerente: um navegador só obedece à regra depois de ter visto o cabeçalho pelo menos uma vez. Por isso a primeiríssima ligação de um visitante novo ainda é uma pequena janela de exposição. Duas coisas a estreitam: um redirecionamento de HTTP para HTTPS (que o leva depressa para a versão segura) e o preload (que remove a janela por completo). É por isso que uma configuração completa emparelha o HSTS com um redirecionamento adequado.

Como é o «bom» — e como é pontuado

A nossa verificação lê o seu cabeçalho em direto e avalia o max-age:

Por isso um cabeçalho que existe mas está definido para uns minutos é tratado como falha — parece configurado mas não está a fazer o trabalho. Aponte para um ano. A verificação também regista se o includeSubDomains e o preload estão presentes.

Como corrigir (gratuito, ~15 minutos)

Entregue esta secção a quem gere o seu site — o seu técnico de TI, programador web ou suporte de alojamento. A correção é gratuita. É um único cabeçalho, ou um interruptor na sua plataforma de alojamento. Não há nada a comprar.

Uma regra de ordem importante primeiro: o HSTS é pegajoso — uma vez ativado, os navegadores vão recusar HTTP simples para o seu domínio durante todo o max-age. Por isso confirme que o HTTPS funciona corretamente no seu site principal e em cada subdomínio antes de o ligar de forma alargada. O caminho seguro é: testar com um valor curto → confirmar que nada quebra → subir para um ano.

Passo 1 — Garanta que o HTTPS já funciona em todo o lado

Visite o seu site e os subdomínios principais por https:// e confirme que carregam de forma limpa com um certificado válido. Confirme também que os pedidos http:// simples redirecionam para https://. (Se não redirecionarem, corrija primeiro o redirecionamento de HTTP para HTTPS — o HSTS pressupõe que está no lugar.)

Passo 2 — Adicione o cabeçalho (escolha a sua plataforma)

Cloudflare (ou CDN semelhante): É o mais fácil. Vá a SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) e ative-o. Defina o Max-Age para 6 meses ou 12 meses, e ative «Apply HSTS policy to subdomains» quando tiver a certeza de que todos os subdomínios estão em HTTPS.

Nginx: adicione dentro do seu bloco server de HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache: garanta que o mod_headers está ativado, depois adicione ao seu virtual host de HTTPS:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS: adicione ao web.config dentro de <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Nota sobre Google Workspace / Microsoft 365: estes alimentam o seu e-mail, não o alojamento do seu site — o HSTS é definido onde quer que o seu site público realmente viva (o seu CDN, servidor web ou construtor de sites), não na administração do Workspace/365. Se o seu site está num construtor como o Squarespace, Wix ou Shopify, o HSTS é normalmente tratado por si; verifique as definições de SSL/segurança deles se a nossa verificação sinalizar.

Passo 3 — Teste em pequeno, depois comprometa-se

Comece com max-age=300 (5 minutos). Confirme que o site continua a carregar na perfeição em todo o lado. Depois suba-o para max-age=31536000 (um ano). É a definição de pontuação máxima.

Passo 4 (opcional, padrão de ouro) — preload

Quando estiver confiante e tiver corrido um cabeçalho de um ano com includeSubDomains durante algum tempo, pode submeter o seu domínio em hstspreload.org para ser incorporado nos navegadores. Isto fecha a janela da primeira visita por completo. Trate-o como um compromisso deliberado — remover um domínio da lista é lento.

Erros comuns

• Definir o max-age demasiado curto. Um valor de uns minutos ou horas parece configurado mas dá quase nenhuma proteção — e a nossa verificação trata tudo abaixo de um dia como falha. Use um ano.
• Ligar o includeSubDomains antes de os subdomínios estarem prontos para HTTPS. Se um subdomínio não estiver totalmente em HTTPS, a regra pegajosa pode torná-lo inalcançável para os visitantes. Ponha primeiro cada subdomínio em HTTPS.
• Adicionar HSTS mas não ter redirecionamento de HTTP para HTTPS. O HSTS pressupõe que os visitantes chegam à versão segura; sem o redirecionamento, a primeira visita fica desnecessariamente exposta. Corrija ambos em conjunto.
• Saltar direto para o preload para «ser minucioso». O preload é difícil de desfazer. Mereça-o gradualmente após um cabeçalho estável de um ano — não se apresse.
• Assumir que o cadeado significa que está coberto. O cadeado e o HSTS são coisas diferentes. Pode ter um certificado perfeito e mesmo assim falhar esta verificação.

Perguntas frequentes