HSTS preload: incluindo seu domínio na lista do navegador

1. O que é HSTS e por que ele não basta sozinho?

HTTP Strict Transport Security (HSTS) é um mecanismo de segurança que instrui navegadores a se comunicarem exclusivamente via HTTPS com um determinado domínio. Isso é feito através do cabeçalho HTTP Strict-Transport-Security:

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

Quando um navegador recebe esse cabeçalho, ele armazena a política e, nas próximas visitas, converte automaticamente qualquer link HTTP para HTTPS antes mesmo de fazer a requisição.

No entanto, o HSTS tradicional possui uma limitação crítica conhecida como TOFU (Trust on First Use). Na primeira visita ao site, se um atacante interceptar a conexão (ataque man-in-the-middle), ele pode redirecionar o usuário para uma versão falsa do site antes que o cabeçalho HSTS seja recebido. Essa janela de vulnerabilidade na primeira conexão é exatamente o que o HSTS Preload visa eliminar.

2. Como funciona a lista de pré-carregamento dos navegadores?

O HSTS Preload é uma lista hardcoded diretamente no código-fonte dos principais navegadores (Chrome, Firefox, Safari, Edge). Quando um domínio está nessa lista, o navegador força HTTPS desde o primeiro byte, sem jamais permitir uma conexão HTTP, mesmo que o usuário digite explicitamente http:// na barra de endereços.

A diferença fundamental é:
- HSTS via cabeçalho: depende da primeira conexão bem-sucedida para aprender a política
- HSTS via preload: a política já está gravada no navegador antes de qualquer requisição

O fluxo de consulta é direto: ao digitar um domínio, o navegador verifica se ele está na lista interna. Se estiver, toda comunicação é forçada a HTTPS, sem exceções.

3. Requisitos técnicos para inclusão no HSTS Preload

Para submeter um domínio ao preload, você precisa atender a requisitos rigorosos:

Cabeçalho HSTS obrigatório:

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

Os parâmetros exigidos são:
- max-age=31536000 (exatamente 1 ano, sem valor menor)
- includeSubDomains (aplica a política a todos os subdomínios)
- preload (sinaliza que o domínio deseja ser incluído na lista)

Requisitos adicionais:
- Certificado SSL válido e configurado corretamente
- Redirecionamento 301 ou 302 de HTTP para HTTPS em todo o domínio
- Todos os subdomínios (inclusive www) devem servir exclusivamente HTTPS
- O domínio raiz e todos os subdomínios devem servir o mesmo cabeçalho HSTS

Exemplo de configuração em servidor Nginx:

server {
    listen 80;
    server_name exemplo.com www.exemplo.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name exemplo.com www.exemplo.com;

    ssl_certificate /caminho/certificado.pem;
    ssl_certificate_key /caminho/chave.key;

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

4. Passo a passo: submetendo seu domínio ao HSTS Preload

O processo de submissão é centralizado no site oficial hstspreload.org:

  1. Verificação automática: acesse https://hstspreload.org e digite seu domínio. O site executará verificações automáticas:
  2. Presença e validade do cabeçalho HSTS
  3. Configuração de redirecionamento HTTP para HTTPS
  4. Certificado SSL válido

  5. Consistência entre domínio principal e subdomínios

  6. Correção de problemas: se alguma verificação falhar, o site indicará exatamente o que precisa ser ajustado. Corrija e reexecute a verificação.

  7. Submissão: após todas as verificações passarem, clique em "Submit" para enviar seu domínio à lista do Chrome (que alimenta os demais navegadores).

  8. Tempo de propagação: a inclusão não é imediata. O Chrome atualiza sua lista a cada versão estável (aproximadamente a cada 6-8 semanas). Após a inclusão no Chrome, os demais navegadores sincronizam suas listas em seus próprios ciclos de atualização.

5. Riscos e considerações críticas para desenvolvedores

A inclusão no HSTS Preload é praticamente irreversível no curto prazo. Remover um domínio da lista exige:
- Solicitação manual no repositório do Chromium
- Aguardar a próxima atualização do navegador (semanas a meses)
- Mesmo após remoção, navegadores com versões antigas ainda forçarão HTTPS

Impactos críticos:
- Subdomínios: todos os subdomínios são forçados a HTTPS, incluindo aqueles que você não controla diretamente
- Ambientes de desenvolvimento: domínios como dev.exemplo.com ou staging.exemplo.com precisam estar preparados
- APIs legadas: serviços que ainda usam HTTP puro simplesmente deixarão de funcionar
- Serviços de terceiros: CDNs, analytics ou widgets carregados via HTTP em subdomínios serão bloqueados

Exemplo de problema comum:

# Cenário: domínio "exemplo.com" com preload ativo
# Subdomínio "api.exemplo.com" ainda em HTTP
# Resultado: usuários não conseguem acessar a API
# Navegador bloqueia a conexão antes mesmo de qualquer requisição

6. Boas práticas de implantação e rollback

Implantação progressiva:
1. Teste em homologação: configure o cabeçalho HSTS sem preload em ambiente de teste
2. Aumento gradual de max-age: comece com valores baixos e aumente progressivamente:
```text
# Semana 1: teste básico
Strict-Transport-Security: max-age=300

# Semana 2: aumentar confiança
Strict-Transport-Security: max-age=86400

# Semana 3: próximo do definitivo
Strict-Transport-Security: max-age=2592000; includeSubDomains

# Após validação completa: versão final
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

  1. Monitoramento contínuo: utilize ferramentas como securityheaders.com para verificar periodicamente os cabeçalhos

Plano de contingência para remoção:
- Solicite remoção no repositório oficial do Chromium: https://github.com/chromium/hstspreload
- Prepare uma página de fallback explicando a indisponibilidade temporária
- Considere manter um canal de comunicação com usuários afetados

7. Casos de uso e quando evitar o HSTS Preload

Cenários ideais:
- Domínios de produção estáveis e maduros
- Todos os subdomínios sob controle total da equipe
- Infraestrutura 100% HTTPS desde o início
- Projetos com equipe dedicada de segurança

Situações para evitar:
- Startups em fase inicial com mudanças frequentes de infraestrutura
- APIs públicas que precisam suportar clientes legados
- Domínios com muitos subdomínios gerenciados por terceiros
- Ambientes com integrações que ainda dependem de HTTP

Alternativa ao preload: configure HSTS com max-age alto (ex.: 1 ano) mas sem a flag preload. Isso oferece proteção após a primeira visita, sem o risco de irreversibilidade. Combine com monitoramento ativo da primeira conexão.

8. Ferramentas e referências para o desenvolvedor