HSTS: o guia completo para ativar Strict-Transport-Security e a preload list

⚡TL;DR

• HSTS (RFC 6797) instrui o navegador a contatar um domínio apenas em HTTPS pelo tempo definido por max-age, neutralizando ataques sslstrip e o downgrade de protocolo
• O cabeçalho é composto por três diretivas: max-age (obrigatória), includeSubDomains (cobre os subdomínios) e preload (opt-in para a lista embutida no Chrome e derivados)
• Para ser elegível à preload list, é preciso max-age maior ou igual a 31.536.000, includeSubDomains, preload e um redirecionamento HTTP para HTTPS no domínio apex
• A preload list é quase irreversível: uma remoção leva vários meses e afeta apenas as versões futuras dos navegadores
• Em abril de 2026, cerca de 120.000 domínios estão na preload list do Chrome e apenas 35,7% dos sites com HSTS ativaram a diretiva preload

Em 2009, Moxie Marlinspike apresenta sslstrip na Black Hat DC. A ferramenta intercepta o tráfego HTTP de um usuário em uma rede pública, substitui em tempo real cada link e redirecionamento HTTPS pelo equivalente HTTP, e então repassa as requisições em texto puro. O usuário acredita estar protegido pelo TLS, enquanto todo o seu tráfego, incluindo cookies de sessão e senhas, sai em texto puro pelo cabo. Na mesma época, a extensão Firefox Firesheep (outubro de 2010) populariza o roubo de sessão no Facebook e Twitter a partir de qualquer hotspot Wi-Fi aberto.

HSTS (HTTP Strict Transport Security) é a resposta a esses ataques. Padronizado pela RFC 6797 em novembro de 2012, ele permite que um servidor HTTPS indique ao navegador que, por um tempo definido, deve se comunicar com o domínio apenas em HTTPS. Quando o cabeçalho é recebido e memorizado, o navegador converte localmente toda requisição http:// para https:// antes mesmo de enviar qualquer pacote pela rede. A janela de interceptação durante o primeiro redirecionamento desaparece.

Em abril de 2026, segundo os estudos de adoção AppSecSanta, apenas 35,7% dos sites que enviam um cabeçalho HSTS usam a diretiva preload. A Chrome HSTS Preload List contém cerca de 120.000 domínios, muito longe do parque HTTPS mundial. O HSTS continua, portanto, subutilizado, frequentemente mal configurado, às vezes ativado com efeitos colaterais inesperados em subdomínios internos em HTTP.

Este guia cobre três objetivos: entender precisamente o que o HSTS faz (e o que ele não faz), configurar o cabeçalho nas cinco stacks web mais comuns, e submeter um domínio à preload list de forma limpa sem quebrar a infraestrutura. Ele se destina a DevOps, SRE, administradores de sistema e CTOs de PMEs que preparam uma auditoria de segurança ou uma submissão preload.

O que é HSTS?

HSTS é um cabeçalho de resposta HTTP enviado por um servidor HTTPS válido. Ele anuncia ao agente de usuário (navegador, biblioteca HTTP, agente automatizado compatível com a RFC 6797) que o domínio deve ser contatado exclusivamente em HTTPS pelo tempo definido na diretiva max-age.

Uma vez que o cabeçalho é recebido em uma conexão TLS válida, o navegador registra localmente o que se chama de "Known HSTS Host". Para qualquer requisição posterior a esse domínio, incluindo aquelas disparadas por um clique em um link http://, um favorito salvo ou um redirecionamento 301 servido por outro servidor, o navegador reescreve a URL para https:// antes do envio. A conversão é feita em memória, no lado cliente, sem requisição de rede intermediária.

Três elementos tornam o HSTS eficaz:

1. A conversão é local. Nenhuma requisição HTTP é enviada para um domínio conhecido em HSTS. Um atacante em posição de man-in-the-middle vê apenas TLS.
2. Os erros de certificado são fatais. Em um domínio com HSTS, o navegador remove o botão "Continuar mesmo assim" que o usuário poderia clicar diante de um erro TLS. Um certificado autoassinado injetado por um atacante dispara um bloqueio, não um aviso.
3. O TTL no lado navegador é prolongado a cada visita. Enquanto o usuário visita o site regularmente, o max-age é renovado a cada resposta, o que impede a expiração.

O cabeçalho é padronizado e suportado por todos os navegadores principais desde 2011. Chromium 4.0.211, Firefox 4.0 (agosto de 2010), Opera 12, Safari no OS X 10.7.3, Edge desde seus primórdios e Internet Explorer 11 o implementam. Em abril de 2026, a compatibilidade é universal: 98% do tráfego web mundial passa por um navegador compatível com HSTS.

O problema que o HSTS resolve

sslstrip e o downgrade de protocolo

Sem HSTS, a proteção HTTPS de um site apresenta um elo fraco: a primeira requisição. Quando um usuário digita captaindns.com na barra de endereço, o navegador emite por padrão uma requisição em HTTP na porta 80. O servidor responde com um redirecionamento 301 para https://captaindns.com. Essa primeira requisição sai em texto puro. Um atacante na rede local pode interceptá-la.

O ataque sslstrip funciona assim: o atacante se posiciona entre o usuário e o gateway de rede (ARP spoofing, rogue access point, comprometimento de DHCP). Ele intercepta a requisição HTTP inicial, repassa para o servidor legítimo em HTTPS, recebe a resposta, substitui todos os https:// por http:// no HTML, nos cabeçalhos e nos cookies, e então a devolve em texto puro ao usuário. Do ponto de vista do navegador, tudo parece normal: uma página HTTP clássica, sem erro. O usuário digita sua senha, que transita em texto puro até o atacante, depois é repassada criptografada ao servidor.

O HSTS neutraliza o sslstrip nas visitas posteriores. Após a primeira requisição HTTPS bem-sucedida, o navegador memoriza o cabeçalho. A segunda visita, mesmo que comece por um clique em um link http:// ou em um redirecionamento de um domínio terceiro, nunca sai em HTTP. O navegador converte localmente a URL antes do DNS, antes do connect(), antes de qualquer tráfego de rede.

A limitação continua sendo a primeira visita. Um navegador que nunca recebeu o cabeçalho HSTS para um domínio é vulnerável ao sslstrip em sua primeira requisição. É exatamente isso que a preload list corrige: a lista embutida no Chrome permite que o navegador conheça os domínios em HSTS desde a saída de fábrica, sem esperar uma primeira conexão.

Roubo de cookies e Firesheep

O Firesheep, publicado em outubro de 2010, demonstrou em larga escala a trivialidade do roubo de sessão em redes públicas. A extensão capturava cookies de sessão do Facebook, Twitter, Flickr e muitos outros sites que ainda serviam seus usuários autenticados em HTTP (ou que migravam para HTTPS apenas na página de login e depois voltavam para HTTP). Em um Wi-Fi de café, clicar em um usuário na interface do Firesheep permitia acessar sua conta em um único gesto.

O HSTS reforça a proteção dos cookies de duas maneiras. Por um lado, ao forçar HTTPS, ele elimina o vazamento do cookie em uma conexão não criptografada. Por outro, combinado com o atributo Secure no cookie (que proíbe seu envio em HTTP) e HttpOnly (que bloqueia o acesso JavaScript), ele fecha os três vetores principais de roubo de sessão pela rede.

Com a diretiva includeSubDomains, o HSTS protege também os cookies definidos sem especificar um domínio explícito. Um cookie posto por www.captaindns.com sem Secure poderia, sem HSTS, ser enviado para api.captaindns.com em HTTP se um sub-recurso fosse carregado lá em texto puro. Com includeSubDomains, todas as requisições a qualquer subdomínio são forçadas para HTTPS, e o cookie permanece criptografado.

Bootstrap MITM e a preload list

A RFC 6797 §14.6 reconhece explicitamente a vulnerabilidade do "bootstrap MITM": um usuário que visita um domínio pela primeira vez ainda não recebeu o cabeçalho HSTS, e sua requisição HTTP inicial permanece interceptável. É a famosa janela de primeira visita.

A preload list do Chromium resolve esse problema embutindo no código-fonte do navegador a lista dos domínios em HSTS. Chrome, Firefox, Safari e Edge importam essa lista a cada atualização. Para um domínio presente, o navegador sabe que deve usar HTTPS desde a primeira requisição, sem nem ter visitado o site. A janela de bootstrap desaparece.

A inscrição é gratuita mas exigente: max-age maior ou igual a 1 ano, includeSubDomains, preload, redirecionamento HTTP para HTTPS no domínio apex. Uma vez inscrito, a remoção leva vários meses, pois é preciso esperar que todas as versões implantadas dos navegadores importem a nova lista. Alguns usuários em versões antigas continuarão forçando HTTPS no seu domínio por anos.

Anatomia do cabeçalho Strict-Transport-Security

A sintaxe é definida pela RFC 6797 §6.1. O cabeçalho é composto por uma diretiva obrigatória (max-age) e duas diretivas opcionais (includeSubDomains, preload), separadas por ponto e vírgula.

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

As diretivas são insensíveis a maiúsculas e minúsculas (IncludeSubDomains é válido mas não canônico). Uma diretiva desconhecida é silenciosamente ignorada pelos navegadores conformes. Se a sintaxe completa for inválida, o cabeçalho inteiro é rejeitado: um único erro de digitação pode desativar sua proteção sem alerta visível. Daí a importância de testar a configuração com uma ferramenta dedicada antes de implantar em produção.

Regras de validade

Várias regras estritas da RFC 6797 influenciam a implantação:

• HTTPS obrigatório. Um cabeçalho HSTS recebido em HTTP é ignorado (§8.1). Essa regra é crucial: ela impede que um atacante man-in-the-middle injete um max-age=0 em HTTP para desativar o HSTS na vítima.
• Certificado válido obrigatório. O cabeçalho só é considerado se a conexão TLS for estabelecida sem erro nem aviso (§8.1). Um certificado expirado, um nome de domínio incorreto, uma cadeia incompleta: tudo isso impede a memorização.
• Apenas a primeira ocorrência. Se vários cabeçalhos HSTS forem enviados na mesma resposta, apenas o primeiro é processado (§8.1). Atenção a middlewares, CDNs e reverse proxies que empilham seus próprios cabeçalhos.
• Sem endereços IP. O HSTS aplica-se apenas a nomes de domínio. Um site acessível via https://192.168.1.1 não é coberto (§8.3).
• Todas as portas. O HSTS cobre o domínio em todas as portas. Uma porta 80 é convertida automaticamente para 443, mas uma porta personalizada permanece em seu número.

Três exemplos canônicos

# Mínimo viável: 1 ano, sem subdomínios
Strict-Transport-Security: max-age=31536000

# Recomendação OWASP: 1 ano com subdomínios
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Elegível à preload list: 2 anos com subdomínios e opt-in preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

A terceira linha é a configuração-alvo para qualquer site público que deseje proteção máxima. Vamos detalhá-la seção por seção.

max-age: a duração da política

max-age é a única diretiva obrigatória. Ela expressa em segundos o tempo durante o qual o navegador deve considerar o domínio como "Known HSTS Host". Alguns valores típicos:

Valor	Duração	Uso
0	Imediato	Remoção da política HSTS
300	5 minutos	Teste inicial, rollout cauteloso
3600	1 hora	Staging, validação curta
86.400	1 dia	Rollout progressivo, D+1
604.800	1 semana	Rollout progressivo, semana 1
31.536.000	1 ano	Limite mínimo da preload list (desde 11 de outubro de 2017)
63.072.000	2 anos	Recomendação corrente para preload

O contador é reiniciado a cada resposta HTTPS que contém o cabeçalho. Concretamente, se o seu site envia max-age=31536000 e um usuário visita uma página por mês, a política nunca se extingue enquanto ele voltar dentro do ano. Inversamente, se você remover bruscamente o cabeçalho, os navegadores que receberam a política continuarão forçando HTTPS até a expiração local. É um efeito catraca: o HSTS só é fácil de ativar em um sentido.

Rollout progressivo recomendado

A OWASP e a cio.gov recomendam uma ativação progressiva para evitar ficar preso com uma política de um ano em um site ainda em implantação. Um plano típico:

1. Dia 0: max-age=300. 5 minutos. Verifique que a cadeia HTTPS funciona, que o redirecionamento HTTP para HTTPS está estável, que todos os conteúdos internos são servidos em HTTPS. Uma remoção é trivial, a política expira em 5 minutos.
2. Dia 1: max-age=86.400. 1 dia. Observe os erros TLS reportados pelo seu sistema de monitoramento, seu WAF e seus logs aplicativos durante 24 horas. Monitore especialmente os redirecionamentos quebrados para recursos internos.
3. Dia 7: max-age=604.800. 1 semana. Se a taxa de erro TLS permanecer estável, passe para uma semana. Essa etapa valida que todos os subdomínios ativos estão acessíveis em HTTPS.
4. Dia 14: max-age=31.536.000. 1 ano. A política está estável, os usuários estão protegidos. Se você visa a preload list, pode ativar includeSubDomains e preload nessa etapa após auditoria.

Esse ritmo permite voltar atrás em cada etapa. Passar diretamente para 1 ano sem teste intermediário é o erro mais frequente: se um único subdomínio esquecido quebrar após a ativação de includeSubDomains, você fica bloqueado por um ano no lado navegador.

Desativação via max-age=0

A RFC 6797 §6.1.1 esclarece que um valor de 0 sinaliza ao navegador para remover a política em cache. É a única forma de retirar o HSTS limpamente: servir durante o tempo anterior um cabeçalho com max-age=0, esperar que os navegadores recebam essa atualização, e então remover completamente o cabeçalho. Atenção, essa desativação só é efetiva em HTTPS (§8.1). Um max-age=0 servido em HTTP é ignorado.

includeSubDomains: estender a proteção

A diretiva includeSubDomains estende a política HSTS a todos os subdomínios do nome de host que a enviou. Enviada de captaindns.com, ela cobre www.captaindns.com, api.captaindns.com, blog.captaindns.com, assim como todos os sub-subdomínios (staging.api.captaindns.com, etc.).

A RFC 6797 §8.2 esclarece que o matching é feito label por label, da direita para a esquerda, insensível a maiúsculas e minúsculas. Uma política HSTS declarada em captaindns.com cobre, portanto, toda a hierarquia DNS abaixo. Inversamente, uma política declarada em www.captaindns.com não cobre nem api.captaindns.com nem captaindns.com, pois a raiz não é um subdomínio de www.

Por que isso é crítico para os cookies

Sem includeSubDomains, um atacante pode contornar o HSTS forçando uma requisição HTTP para um subdomínio. Cenário clássico:

1. O usuário se conecta a https://captaindns.com protegido por HSTS, recebe um cookie de sessão sem o atributo Secure.
2. O atacante injeta uma imagem <img src="http://blog.captaindns.com/pixel.png"> em uma página visitada pela vítima (via XSS, um fórum, ou um man-in-the-middle em outro site).
3. O navegador emite a requisição em HTTP para blog.captaindns.com e anexa automaticamente o cookie do domínio pai (pois os cookies se propagam para os subdomínios).
4. O atacante, posicionado na rede, captura o cookie em texto puro.

Com includeSubDomains, a requisição para blog.captaindns.com é convertida em HTTPS antes do envio. O cookie permanece criptografado no cabo. É por essa razão que o OWASP Cheat Sheet recomenda sistematicamente includeSubDomains sempre que possível.

As armadilhas a evitar

includeSubDomains tem um efeito colateral radical: todos os subdomínios, incluindo aqueles que não são públicos, devem servir HTTPS. Aqui estão as armadilhas mais frequentes, documentadas pelas comunidades DevOps:

• Ferramentas internas em HTTP. Um grafana.interno.captaindns.com servido em HTTP na rede privada se tornará inacessível para os usuários que já memorizaram a política HSTS de captaindns.com.
• Ambientes de staging. Um staging.captaindns.com com um certificado autoassinado provoca erros TLS fatais para as equipes que se conectam a partir de máquinas que visitaram a produção.
• Subdomínios históricos. Um antigo mail.captaindns.com servido por um fornecedor terceiro em HTTP pode quebrar os links em emails antigos.
• Subdomínios terceiros. Um subdomínio delegado a um fornecedor SaaS (support.captaindns.com apontando para Zendesk, por exemplo) deve oferecer HTTPS com um certificado válido para o nome delegado.

Antes de ativar includeSubDomains, faça um inventário exaustivo. As equipes mais experientes passam por uma fase de "shadow mode": ativar HSTS sem includeSubDomains por várias semanas, correlacionar com os logs DNS para identificar os subdomínios ativos, migrar apenas após auditoria completa.

Alternativa: HSTS no nível do subdomínio

Se alguns subdomínios não puderem ser migrados para HTTPS (legacy, contrato externo), uma alternativa é declarar HSTS individualmente em cada subdomínio que pode, sem includeSubDomains no nível raiz. É mais verboso mas evita quebrar os subdomínios em HTTP. O custo: cada subdomínio deve manter sua própria política, e você não pode ser elegível à preload list sem includeSubDomains no apex.

preload: a lista embutida

A diretiva preload é um opt-in pelo qual o proprietário do domínio declara sua intenção de figurar na Chrome HSTS Preload List. Sem essa diretiva, o domínio não será aceito na submissão, mesmo que cumpra todos os outros critérios.

As quatro condições de elegibilidade

O hstspreload.org exige, desde 11 de outubro de 2017, que o cabeçalho servido pelo domínio apex respeite quatro condições:

1. max-age maior ou igual a 31.536.000 (1 ano). Um max-age mais curto é recusado.
2. includeSubDomains presente. A preload list cobre sempre a árvore DNS completa.
3. preload presente. Declaração de intenção explícita.
4. Redirecionamento HTTP para HTTPS no domínio apex. Se o servidor aceita conexões na porta 80, ele deve responder com um 301 para HTTPS. O redirecionamento também deve servir o cabeçalho HSTS.

Um certificado TLS válido e a capacidade de servir todos os subdomínios (incluindo www) em HTTPS também são exigidos. A ferramenta de submissão testa automaticamente essas condições antes de aceitar o pedido.

O processo de submissão

Uma vez cumpridas as condições, a submissão é feita em três etapas:

1. Teste automático. Em hstspreload.org, insira seu domínio. O serviço testa o cabeçalho HSTS, o redirecionamento HTTP para HTTPS, a disponibilidade HTTPS dos subdomínios www. Os erros são detalhados.
2. Submissão. Se o teste passar, um botão "Submit to the HSTS preload list" se torna disponível. Confirme após ler os avisos sobre a irreversibilidade.
3. Integração. O domínio passa para o status pending. Ele é integrado à lista fonte do Chromium, propagada para Firefox, Safari, Edge. A propagação completa leva cerca de 6 a 12 semanas, dependendo dos ciclos de release dos navegadores.

Você pode verificar o status a qualquer momento via curl https://hstspreload.org/api/v2/status?domain=captaindns.com.

A irreversibilidade

Esse é o ponto mais importante a entender. Uma vez na preload list, uma remoção leva vários meses e afeta apenas as versões futuras dos navegadores. Os usuários em uma versão antiga continuarão forçando HTTPS no seu domínio por anos. É particularmente problemático em três casos:

• Venda de domínio. Se você ceder captaindns.com a um terceiro que deseja usá-lo em HTTP, seu opt-in o impedirá.
• Descomissionamento de infraestrutura. Se você desativar um serviço e o domínio for retomado por outra coisa, o HSTS permanece em cache.
• Rollback de emergência. Se um ataque ou incidente corromper sua cadeia TLS, você não pode desativar HTTPS em emergência.

A página hstspreload.org/removal/ documenta o procedimento de remoção. Ela avisa explicitamente que o processo pode levar vários meses e que alguns usuários nunca verão a remoção.

Adoção real em abril de 2026

O estudo APNIC 2023 e os dados de 2026 mostram que a adoção continua baixa apesar dos benefícios:

Estatística	Valor
Domínios na preload list	~120.000
Tamanho do arquivo embutido	~18 MB
Sites com HSTS que ativam preload	35,7%
Top 20 mundial na preload list	8 de 20
Adoção finanças / banco	Muito baixa

Google, GitHub, Twitter, Facebook, PayPal figuram na lista. Por outro lado, metade dos 20 maiores sites mundiais não tem HSTS no domínio apex. Os setores regulamentados (finanças, saúde) estão atrasados, frequentemente por conservadorismo quanto à reversibilidade.

Guia passo a passo: ativar HSTS por stack

Cobrimos aqui os cinco ambientes mais implantados em 2026. Para cada stack, a configuração apresenta primeiro o mínimo viável, depois a versão elegível ao preload.

Nginx

No Nginx, o cabeçalho HSTS é emitido via a diretiva add_header no bloco server que escuta na porta 443. O parâmetro always é essencial: sem ele, o Nginx adiciona o cabeçalho apenas nas respostas 2xx e 3xx, e o esquece nas 4xx e 5xx. Um atacante poderia então forçar um erro 404 para contornar a proteção.

Configuração mínima:

server {
    listen 443 ssl http2;
    server_name captaindns.com;

    ssl_certificate /etc/letsencrypt/live/captaindns.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/captaindns.com/privkey.pem;

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

    # restante da configuração
}

Configuração elegível ao preload:

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

Atenção aos blocos aninhados. O Nginx aplica add_header apenas no nível mais específico que contém um add_header. Se você declarar HSTS no nível server e depois redeclarar outro add_header em um bloco location, o HSTS do nível server desaparece nessa location. A solução: repetir a diretiva HSTS em cada location ou usar more_set_headers do módulo nginx_headers_more.

O bloco de escuta na porta 80 deve efetuar o redirecionamento 301 para HTTPS:

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

Nunca adicione o cabeçalho HSTS nesse bloco da porta 80. Os navegadores o ignoram (RFC 6797 §8.1), mas a presença confunde as auditorias e indica uma configuração aproximada.

Apache HTTPD

O Apache gerencia HSTS via o módulo mod_headers. No Debian e derivados, ative-o com sudo a2enmod headers e depois sudo systemctl reload apache2. A diretiva Header always set escreve o cabeçalho em todas as respostas, incluindo os erros.

Configuração mínima em /etc/apache2/sites-available/captaindns.com.conf ou em um .htaccess na raiz do site:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Configuração elegível ao preload:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Como no Nginx, o cabeçalho deve ser colocado apenas no VirtualHost que escuta na porta 443. O VirtualHost da porta 80 deve conter um redirecionamento para HTTPS, tipicamente via mod_rewrite ou a diretiva Redirect permanent:

<VirtualHost *:80>
    ServerName captaindns.com
    ServerAlias www.captaindns.com
    Redirect permanent / https://captaindns.com/
</VirtualHost>

A colocação em .htaccess também funciona, o que é útil para hospedagens compartilhadas. É preciso, no entanto, verificar que a diretiva AllowOverride autoriza Headers na configuração do servidor.

Cloudflare

A Cloudflare oferece uma gestão nativa de HSTS em seu painel. Duas vantagens: nenhuma modificação de configuração de servidor, e a Cloudflare serve o cabeçalho em todas as respostas que atravessam o CDN, incluindo as páginas de erro gerenciadas no edge.

Para ativar HSTS na Cloudflare:

1. Conecte-se ao painel da Cloudflare e selecione o domínio.
2. Vá em SSL/TLS e depois Edge Certificates.
3. Role até HTTP Strict Transport Security (HSTS) e clique em Enable HSTS.
4. Leia o aviso, marque "I understand", e depois Next.
5. Configure as opções:
   • Max Age: escolha 12 meses no mínimo (18 ou 24 meses para preload).
   • Apply HSTS policy to subdomains: ativa includeSubDomains.
   • Preload: ativa a diretiva preload.
   • No-Sniff Header: adiciona X-Content-Type-Options: nosniff (recomendado).
6. Clique em Save.

A Cloudflare adiciona imediatamente o cabeçalho a todas as respostas. Verifique via curl -I https://captaindns.com que o cabeçalho está presente.

Atenção: a Cloudflare serve HSTS mesmo se sua origem estiver em HTTP atrás da Cloudflare. É uma armadilha clássica: você pode tornar seu site elegível à preload list enquanto a origem está tecnicamente insegura. Se um dia você mudar de CDN ou passar para DNS Only, os visitantes cairão em uma origem HTTP bloqueada pelo HSTS. Antes de ativar preload via Cloudflare, certifique-se de que sua origem está realmente em HTTPS.

AWS CloudFront

O CloudFront gerencia HSTS via as Response Headers Policies, introduzidas em 2021. Você pode usar uma policy gerenciada pela AWS (Managed-SecurityHeadersPolicy) ou criar uma policy custom para um controle fino.

Via o console AWS:

1. CloudFront → Policies → Response headers → Create response headers policy.
2. Seção Strict-Transport-Security: ative a caixa.
3. Preencha:
   • Max-age (seconds): 63072000 para preload, 31536000 caso contrário.
   • Include subdomains: marque para preload.
   • Preload: marque para preload.
   • Override origin: marque para que o CloudFront sobrescreva o cabeçalho eventualmente enviado pela origem (recomendado).
4. Crie a policy, e depois anexe-a à sua distribuição CloudFront na aba Behaviors.

Via Terraform:

resource "aws_cloudfront_response_headers_policy" "security" {
  name = "captaindns-security-headers"

  security_headers_config {
    strict_transport_security {
      access_control_max_age_sec = 63072000
      include_subdomains         = true
      preload                    = true
      override                   = true
    }
  }
}

resource "aws_cloudfront_distribution" "captaindns" {
  # ...
  default_cache_behavior {
    # ...
    response_headers_policy_id = aws_cloudfront_response_headers_policy.security.id
  }
}

A vantagem de uma Response Headers Policy em relação a uma CloudFront Function é o custo: gratuita, sem cobrança por requisição.

Caddy

O Caddy se distingue: ele não fornece HSTS por padrão, voluntariamente. Matt Holt, seu criador, considera que uma ativação automática seria perigosa para os usuários que poderiam querer remover HTTPS depois.

A ativação manual é simples, via a diretiva header no Caddyfile:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    # restante da configuração
}

Para a versão preload:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    }
}

O Caddy gerencia automaticamente o redirecionamento HTTP para HTTPS, e renova seus certificados Let's Encrypt em segundo plano. Você pode, portanto, ativar HSTS com confiança desde o dia 1, pois o Caddy garante a disponibilidade HTTPS no longo prazo.

Para um reverse proxy, o padrão é idêntico, mas coloque a diretiva header no bloco que serve o front:

captaindns.com {
    header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    reverse_proxy localhost:3000
}

Proceder ao precarregamento HSTS

Uma vez que o cabeçalho HSTS esteja estável no seu domínio apex com as três diretivas, você pode submeter à preload list. Não apresse essa etapa: a decisão é quase irreversível.

Checklist antes da submissão

Percorra essa lista. Cada caixa deve ser marcada.

• Todos os subdomínios públicos (www, api, mail, blog, shop) servem HTTPS com um certificado válido.
• Todos os subdomínios internos (staging, admin, monitoring, ci) servem HTTPS ou estão fechados ao exterior.
• O domínio apex serve https:// com um certificado cujo SAN cobre o apex.
• O redirecionamento HTTP para HTTPS no domínio apex retorna um 301 (não um 302).
• O cabeçalho HSTS no apex contém max-age=31536000 (ou mais), includeSubDomains e preload.
• A cadeia TLS está completa (nenhum certificado intermediário ausente).
• Você não tem nenhum subdomínio gerenciado por um terceiro que possa não suportar HTTPS (ex.: um blog antigo em HTTP em uma hospedagem legacy).
• Você viveu pelo menos 30 dias com a configuração final para capturar os casos limite.

Faça o teste automático em hstspreload.org. Se uma luz vermelha aparecer, corrija antes de submeter. Os erros típicos: certificado autoassinado em www, redirecionamento 302 em vez de 301, cabeçalho HSTS ausente na resposta 301 do HTTP.

Submeter o domínio

Uma vez que o teste esteja verde, clique no botão de submissão, insira seu endereço de email e confirme. O domínio passa para o status pending. Em 3 a 4 semanas, ele é integrado ao código-fonte do Chromium. Em 6 a 12 semanas, está presente nas versões estáveis do Chrome, Firefox, Safari e Edge.

Você pode acompanhar o status:

curl "https://hstspreload.org/api/v2/status?domain=captaindns.com"

Os status possíveis: unknown (desconhecido), pending (pendente), preloaded (integrado), rejected (rejeitado, ver detalhes).

Manter a política após a submissão

Mantenha o cabeçalho HSTS com as três diretivas em permanência. Algumas empresas removem preload após a submissão acreditando que está terminado: é um erro. A presença contínua da diretiva é verificada nas auditorias periódicas da preload list pela equipe Chromium, e sua ausência pode acarretar uma remoção.

Remover um domínio (procedimento longo)

Se você precisar remover seu domínio da preload list:

1. Vá em hstspreload.org/removal/.
2. Forneça as razões (venda de domínio, migração de infraestrutura, etc.).
3. Sirva max-age=0 no seu domínio durante o período de remoção.
4. Espere 4 a 12 semanas para a integração no Chromium.
5. Espere mais 6 a 12 meses para que a maioria dos usuários atualize seu navegador.

Durante esse período, seu domínio permanece forçado em HTTPS na maioria dos navegadores. Planeje o procedimento antes de não poder mais servir TLS.

Erros frequentes e antipadrões

Ativar HSTS sem ter testado a cadeia HTTPS

É o erro mais custoso. Ativar max-age=31536000 antes de validar que todos os endpoints servem HTTPS corretamente bloqueia os usuários por um ano. Sempre comece em max-age=300 e progrida por etapas.

Esquecer always no Nginx

Sem always, add_header só é emitido em respostas 2xx/3xx. Em uma página de erro 500 ou 404, o cabeçalho HSTS desaparece. Se essa página for a primeira vista por um novo visitante, a política não é memorizada. Um atacante pode explorar essa brecha.

Enviar HSTS em HTTP

Tecnicamente, os navegadores ignoram o cabeçalho recebido em HTTP (RFC §8.1). Na prática, isso indica uma configuração aproximada e atrapalha as auditorias. Envie HSTS apenas nos blocos HTTPS.

Cookies sem o atributo Secure

O HSTS força HTTPS no nível navegador, mas em um navegador não compatível ou na primeira visita, um cookie sem Secure pode vazar. Combine sistematicamente HSTS e Set-Cookie: ... ; Secure; HttpOnly; SameSite=Lax.

Preload sem includeSubDomains

Tecnicamente impossível: o serviço hstspreload.org recusa qualquer submissão sem includeSubDomains. Algumas configurações implantadas ativam preload sem includeSubDomains. Resultado: o cabeçalho é servido mas o domínio nunca é integrado, o que cria uma falsa impressão de proteção.

Certificado autoassinado em staging

Um desenvolvedor se conecta a staging.captaindns.com servido por um certificado autoassinado, e depois visita a produção captaindns.com. Após a ativação do HSTS com includeSubDomains, o desenvolvedor não pode mais acessar staging: o navegador recusa o certificado autoassinado. Solução: use um certificado Let's Encrypt via DNS challenge, ou coloque o staging em um domínio dedicado não coberto pela política.

Redirecionamento 302 em vez de 301

O teste preload exige um 301 "Moved Permanently" no redirecionamento HTTP para HTTPS. Um 302 "Found" é rejeitado. Verifique com curl -I http://captaindns.com.

Ausência de HSTS na resposta de redirecionamento

Quando o navegador recebe a primeira resposta 301 em HTTP, ele segue o redirecionamento para HTTPS. É a segunda resposta (em HTTPS) que deve conter HSTS. Algumas configurações, por esquecimento, colocam HSTS no redirecionamento HTTP (sem efeito) e o esquecem no destino HTTPS.

HSTS em uma meta tag HTML

HSTS é um cabeçalho HTTP, não um elemento HTML. <meta http-equiv="Strict-Transport-Security" content="..."> é ignorado por todos os navegadores. Sempre envie o cabeçalho no lado servidor.

Esquecer de testar após mudança de infraestrutura

Após migração para um novo CDN, mudança de reverse proxy ou atualização de Terraform, o cabeçalho HSTS pode desaparecer silenciosamente. Integre um teste automatizado ao seu CI/CD que verifica a presença do cabeçalho em todas as rotas principais.

Verificar sua configuração HSTS com a CaptainDNS

Na CaptainDNS, fornecemos uma ferramenta dedicada para auditar sua configuração HSTS em 3 segundos, sem conta nem inscrição: o teste HSTS da CaptainDNS.

A ferramenta efetua três verificações em paralelo:

1. Análise do cabeçalho Strict-Transport-Security: a ferramenta consulta o domínio em HTTPS, captura o cabeçalho e parseia suas diretivas. Ela detecta max-age, includeSubDomains, preload, assim como os valores entre aspas ou mal formados que alguns servidores retornam.
2. Consulta à preload list do Chrome: via a API hstspreload.org, ela recupera o status real do seu domínio (unknown, pending, preloaded, rejected) e a elegibilidade à submissão.
3. Cálculo de um grade acionável: o resultado é resumido por um grade entre cinco níveis: missing (nenhum cabeçalho), weak (max-age muito baixo), good (max-age suficiente), preload-ready (elegível mas não submetido), preloaded (na lista do Chrome).

Para cada grade inferior a preloaded, a ferramenta fornece os snippets de configuração prontos para colar para Nginx, Apache e Cloudflare. Após a implantação da correção, relance o teste para confirmar a passagem ao grade superior.

Para uma visão mais ampla dos seus cabeçalhos de segurança (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), use também o nosso Headers Viewer, que exibe a lista fiel dos cabeçalhos na ordem de chegada. Para testar seu redirecionamento HTTP para HTTPS, o Redirect Checker segue a cadeia completa de redirecionamentos.

Se seu objetivo vai além de HSTS e cobre a segurança TLS do parque de email, consulte o nosso verificador de certificados TLS para inspecionar os certificados TLS ou o check DANE/TLSA para adicionar uma verificação DANE/TLSA aos seus servidores de email.

FAQ

O que é HSTS, em uma frase?

HSTS é um cabeçalho de resposta HTTP que indica ao navegador para contatar um domínio apenas em HTTPS pelo tempo definido na diretiva max-age, o que neutraliza os ataques que tentam forçar uma conexão em texto puro.

Por que meu site marca "HSTS missing" em um teste?

Três causas são possíveis: o cabeçalho não é enviado de jeito nenhum, é enviado apenas em HTTP (portanto ignorado pelos navegadores), ou é enviado em HTTPS mas com sintaxe inválida. Use uma ferramenta como o teste HSTS da CaptainDNS para isolar o problema preciso.

Qual valor de max-age escolher?

Para um rollout cauteloso, comece em max-age=300 (5 minutos), e depois aumente progressivamente por etapas (1 dia, 1 semana, 1 ano). Para uma produção estável, max-age=31536000 (1 ano) é o mínimo recomendado. Para a preload list, max-age=63072000 (2 anos) é o valor mais comum. Acima disso, não há ganho de segurança adicional.

O HSTS protege a primeira visita?

Não. Sem preload list, um navegador que visita seu domínio pela primeira vez emite uma requisição HTTP antes de receber o cabeçalho HSTS. Essa janela de bootstrap permanece vulnerável a um ataque man-in-the-middle. A preload list do Chrome resolve esse problema embutindo a lista dos domínios conhecidos no código-fonte do navegador.

Posso ativar HSTS sem includeSubDomains?

Sim, mas a proteção é menos robusta. includeSubDomains cobre notadamente os cookies definidos no nível do domínio pai. Sem essa diretiva, um atacante pode forçar uma requisição HTTP para um subdomínio não HTTPS para capturar os cookies. Se todos os seus subdomínios podem servir HTTPS, ative-a. Caso contrário, aceite uma proteção parcial.

O que acontece se eu desativar o HSTS por engano?

Nada visível para o usuário enquanto a política previamente recebida não estiver expirada. O navegador continua forçando HTTPS até o fim do max-age. Para desativar limpamente, sirva max-age=0 durante o tempo equivalente ao seu antigo max-age (pelo menos 1 ano em produção estável), e depois remova completamente o cabeçalho.

Como testar HSTS localmente sem poluir meu navegador?

Use um domínio de teste dedicado (por exemplo, um domínio .test reservado pela IETF ou um second-level domain distinto da sua produção) com um certificado Let's Encrypt obtido via DNS challenge. Evite testar HSTS no seu domínio de produção a partir da sua máquina: uma má configuração pode bloqueá-lo durante todo o tempo de max-age. Em desenvolvimento, você também pode limpar o cache HSTS do Chrome via chrome://net-internals/#hsts, aba "Delete domain security policies".

Devo remover HSTS de um site que não usa mais HTTPS?

Não, você não pode remover HSTS simplesmente. Uma vez que um navegador memorizou a política, ele recusará qualquer conexão HTTP até a expiração de max-age. Antes de migrar um site para HTTP (o que é desaconselhado), você deve servir max-age=0 em HTTPS durante o tempo anterior e esperar a expiração nos navegadores dos seus visitantes.

A preload list é reversível?

Tecnicamente sim, na prática não. O procedimento de remoção em hstspreload.org leva 4 a 12 semanas para a integração no Chromium, e depois mais 6 a 12 meses para que a maioria dos usuários atualize seu navegador. Alguns usuários nunca verão a remoção. Antes de submeter à preload list, certifique-se de que poderá manter HTTPS nesse domínio por anos.

O HSTS substitui o redirecionamento 301 HTTP para HTTPS?

Não, ele o complementa. O redirecionamento 301 é necessário para a primeira visita e para os usuários que nunca receberam o cabeçalho HSTS. O HSTS assume nas visitas seguintes convertendo as URLs no lado navegador antes do envio pela rede. Os dois mecanismos devem coexistir.

Quantos sites estão na preload list em 2026?

Cerca de 120.000 domínios estão inscritos na preload list do Chromium em abril de 2026. O arquivo fonte tem cerca de 18 MB. Entre esses domínios, encontram-se a maioria dos grandes atores tech (Google, GitHub, Twitter, Facebook, PayPal) mas apenas metade dos 20 maiores sites mundiais. Os setores de finanças, saúde e administração permanecem muito atrasados.

Conclusão: HSTS, a base indispensável de qualquer infraestrutura HTTPS

HSTS é a peça que faltava em uma configuração HTTPS robusta. Sem ele, a primeira requisição de cada visita sai em texto puro pela rede, e todo o resto do tráfego depende do bom funcionamento do redirecionamento 301. Com ele, o navegador assume o controle e converte localmente cada URL antes mesmo que o resolvedor DNS seja consultado.

Três pontos a reter:

1. Ative HSTS progressivamente. Comece em max-age=300 para validar sua cadeia HTTPS, e depois aumente por etapas em 2 a 4 semanas. Monitore os erros TLS em cada etapa.
2. Adicione includeSubDomains assim que seus subdomínios estiverem prontos. Essa diretiva fecha a porta aos ataques por subdomínio e protege seus cookies em profundidade. Faça um inventário exaustivo antes de ativá-la.
3. Considere a preload list para a proteção máxima. Ela neutraliza a vulnerabilidade do bootstrap MITM, mas é um compromisso quase irreversível. Submeta apenas após 30 dias de estabilidade em produção.

Para testar sua configuração HSTS agora mesmo, vá ao teste HSTS gratuito da CaptainDNS. A ferramenta calcula seu grade, analisa suas diretivas, consulta a preload list do Chrome e fornece os snippets Nginx, Apache e Cloudflare prontos para colar. Sem conta requerida, resultado em 3 segundos.