HSTS preload

O que esta verificação faz

Procura o teu domínio na lista HSTS preload do Chromium — uma lista estática de domínios só-HTTPS compilada diretamente no Chrome, Firefox, Safari, Edge e Brave. Para domínios listados, os navegadores recusam ligações HTTP simples desde o primeiro pedido, antes de qualquer cabeçalho ser visto.

A verificação devolve um de: preloaded, pending submission, not preloaded ou removal in progress.

Porque é importante

O HSTS fecha a janela de ataque de downgrade — mas só depois de um navegador ter visto o cabeçalho uma vez. A primeira visita que um utilizador faz ao teu domínio ainda é em texto simples. Numa Wi-Fi hostil ou com um router comprometido, um atacante pode intercetar esse primeiro pedido, retirar o redirecionamento para HTTPS e servir uma versão maliciosa do teu site antes de o HSTS sequer entrar em ação.

O preloading elimina a janela. O navegador sabe que o teu domínio é só-HTTPS antes de o utilizador escrever o URL. Mesmo numa instalação totalmente nova com zero histórico, o primeiro pedido é encriptado.

Isto importa mais para: banca, saúde, contas com credenciais valiosas, fluxos de pagamento e qualquer site onde a primeira visita possa comprometer o utilizador. Para um site de marketing sem auth, o preload é um sinal simpático de maturidade operacional mas não load-bearing.

O tradeoff: o preloading é difícil de desfazer. A remoção costuma demorar 6–12 semanas via o canal estável do Chrome, e utilizadores em versões mais antigas do navegador ficam bloqueados ainda mais tempo. Submete apenas quando tens a certeza de que o teu domínio falará HTTPS para sempre.

Como corrigir

1. Verifica os pré-requisitos antes da submissão.

Pela política do hstspreload.org, o teu site deve:

• Servir um certificado HTTPS válido no domínio apex e em www.
• Redirecionar HTTP → HTTPS no mesmo host (vê redirecionar HTTP para HTTPS).
• Enviar um cabeçalho HSTS em cada resposta HTTPS com:
  • max-age ≥ 31536000 (um ano)
  • includeSubDomains
  • preload
• Servir todos os subdomínios também sobre HTTPS — includeSubDomains significa isso.

O cabeçalho pronto para produção:

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

Dois anos é o valor convencional quando estás confiante.

2. Configura o cabeçalho.

nginx:

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

Apache:

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

Cloudflare: SSL/TLS → Edge Certificates → HSTS → define max-age para 12+ meses, ativa Include subdomains, ativa Preload, ativa No-Sniff Header.

3. Verifica antes de submeter.

curl -sI https://oteudominio.com | grep -i strict-transport-security
curl -sI https://www.oteudominio.com | grep -i strict-transport-security
curl -sI https://qualquersubdominio.oteudominio.com | grep -i strict-transport-security

Os três devem devolver o cabeçalho com as três diretivas. Se um subdomínio não tiver o cabeçalho ou servir non-HTTPS, a submissão será rejeitada.

4. Submete em hstspreload.org.

Coloca o domínio em hstspreload.org, aceita os avisos, clica Submit. O formulário corre a mesma verificação que a manual acima. Domínios aprovados aterram no próximo release do Chrome (6–12 semanas até estável). Firefox, Safari e Edge puxam da lista do Chromium ao seu próprio ritmo.

5. Planeia o pior cenário antes de submeteres.

Percorre estes modos de falha e confirma que cada um está OK:

• Certificado expira sem vigilância. Os utilizadores recebem um erro duro sem fallback HTTP. Automatiza a renovação (Let’s Encrypt + timer do certbot ou o cert gerido do teu cloud provider).
• Subdomínio precisa de HTTP (dispositivo legacy, IoT, ferramenta interna). Não funcionará. Estás trancado em HTTPS-em-toda-a-parte para o eTLD+1.
• Aquisição / venda do domínio. O novo dono herda a entrada de preload até a remoção completar. Compradores deviam verificar a lista de preload antes da compra.
• Domínio interno submetido por engano. A remoção demora meses. Submete apenas domínios públicos de produção.

6. Remoção, se alguma vez precisares.

Submete um pedido de remoção em hstspreload.org. O domínio é retirado da próxima atualização Chromium (~6 semanas). Instalações de navegadores mais antigos ficam bloqueadas enquanto o max-age o disser, e utilizadores que não atualizam o Chrome podem ficar presos por um ano ou mais. Baixa o max-age para um valor pequeno (ex. 300) bem antes para limitar o lock-in residual.

Perguntas frequentes

Preciso do preload se já tenho HSTS?

Para a maioria dos sites de marketing, não. O HSTS simples protege toda a gente depois da primeira visita, o que é bom o suficiente quando não há auth ou fluxo de pagamento. O preload importa quando (a) lidas com credenciais, dinheiro ou PHI, (b) podes garantir HTTPS para sempre e (c) já enviaste HSTS há pelo menos alguns meses sem problemas.

Quanto tempo demora a aparecer mesmo no Chrome?

Submissão até primeiro release estável do Chrome: tipicamente 6–12 semanas. O formulário dirá “pending” até à próxima compilação da lista, depois “pending preload” enquanto entrega pelos canais de release do Chrome (canary → dev → beta → stable). Firefox, Safari e Edge puxam da lista do Chromium aos seus próprios ciclos de atualização — conta 3–6 meses para cobertura ampla.

Posso preload apenas um subdomínio, como app.example.com?

Sim, mas só se o eTLD+1 pai ainda não estiver preloaded. Submete app.example.com diretamente. Aplicam-se os mesmos pré-requisitos (cabeçalho HSTS com diretiva preload, HTTPS em todo o lado nesse hostname). Esta é a abordagem certa quando controlas um subdomínio mas não consegues comprometer toda a organização com HTTPS-para-sempre.