Um site criado por IA pode abrir por HTTPS, redirecionar acessos HTTP e ainda deixar a primeira conexão exposta a uma tentativa de downgrade. Strict-Transport-Security, ou HSTS, permite que o navegador memorize que um hostname deve ser acessado somente por transporte seguro.

O header é curto. A decisão operacional não é. Um max-age longo, includeSubDomains ou preload aplicado antes de revisar DNS, certificados e serviços antigos pode tornar um hostname legítimo inacessível para quem já recebeu a política.

Este guia mostra como inventariar o domínio, ativar HSTS em etapas, validar a resposta publicada e preparar rollback sem vender uma configuração irreversível como checklist automático.

Entenda o que HSTS muda

Depois de receber uma política válida por HTTPS e sem erro de certificado, o navegador passa a tratar o host como HSTS durante o período indicado. Referências http:// para esse host são convertidas para HTTPS antes da conexão insegura, e erros de transporte seguro deixam de oferecer o mesmo caminho de exceção ao usuário.

O RFC 6797 define a política, seu armazenamento por hostname e o header de resposta que a declara.

HSTS não:

  • emite ou renova certificado;
  • corrige DNS;
  • remove mixed content do HTML;
  • protege um domínio diferente;
  • substitui cookies Secure;
  • corrige conteúdo vulnerável servido por HTTPS;
  • transforma um redirect em política persistente por si só.

Antes de chegar ao header, feche a revisão de mixed content e confirme que a URL final funciona sem avisos de TLS.

Faça um inventário do domínio inteiro

Comece pelo hostname que emitirá a política e pelas fronteiras que podem ser afetadas:

domínio base:
URL padrão do Site:
domínios próprios:
subdomínios públicos:
subdomínios internos:
hostnames antigos ainda no DNS:
certificados e responsáveis:
serviços que ainda aceitam HTTP:
redirects atuais:
CDN, proxy ou origem que controla os headers:

Consulte DNS, inventário de certificados e equipes responsáveis. Não limite a busca aos links do site. includeSubDomains alcança hostnames abaixo do domínio mesmo quando eles não aparecem na aplicação principal.

Exemplos que costumam ser esquecidos:

  • mail, status, api e files;
  • ambientes antigos como staging e legacy;
  • painéis de fornecedores;
  • endpoints internos resolvidos apenas na rede corporativa;
  • subdomínios delegados a outra equipe;
  • registros que existem, mas não respondem a uma navegação comum.

Para cada hostname, registre se HTTPS funciona, quem renova o certificado, se existe redirect e qual seria o impacto de uma falha sem possibilidade de exceção no navegador.

Diferencie as diretivas

Uma política inicial pode conter apenas:

Strict-Transport-Security: max-age=300

max-age é o tempo, em segundos, durante o qual o navegador mantém o host como HSTS a partir da resposta recebida. Uma nova resposta válida atualiza esse prazo.

As opções ampliam o compromisso:

Diretiva Efeito
max-age=... mantém a política para o hostname que a emitiu
includeSubDomains estende a política a todos os níveis abaixo desse hostname
preload sinaliza intenção de entrar em uma lista incorporada aos navegadores

preload não faz parte do mecanismo básico do RFC e não insere o domínio em lista nenhuma sozinho. A inclusão exige submissão e requisitos adicionais. O próprio serviço de preload do Chromium recomenda entender as consequências de longo prazo e hoje não recomenda preload como passo padrão.

Ative em etapas

Não comece com um ano, subdomínios e preload. Use uma progressão observável na camada que controla a resposta HTTPS.

Uma sequência possível:

Strict-Transport-Security: max-age=300

Depois de validar o período completo:

Strict-Transport-Security: max-age=604800

E só depois de cobrir todos os hostnames desejados:

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

Os tempos são marcos de rollout, não valores universais. Em cada etapa:

  1. confirme emissão e renovação de certificados;
  2. teste home, rotas, APIs, downloads e redirects;
  3. monitore erro TLS, suporte e conversão;
  4. espere o max-age da etapa antes de ampliar o compromisso;
  5. registre quem aprovou a próxima fase.

Teste com pessoas ou sessões controladas primeiro quando a infraestrutura permitir. Um navegador que recebeu a política continua aplicando-a mesmo depois que você remove o header, até o prazo expirar ou receber uma política de remoção válida.

Trate includeSubDomains como decisão de domínio

Aplicar HSTS no apex sem includeSubDomains não cobre automaticamente www, app ou api. Com a diretiva, a política alcança todos os subdomínios, inclusive os que outra equipe opera.

Antes de ativá-la:

  • todos os registros existentes precisam suportar HTTPS;
  • certificados devem renovar sem intervenção frágil;
  • serviços internos precisam ser testados nos clientes que os usam;
  • hostnames abandonados devem ser removidos ou corrigidos;
  • proprietários de subdomínios precisam concordar com o compromisso;
  • o plano de incidentes deve considerar falha de DNS, CDN e certificado.

A configuração de domínios próprios no Site no Ar trata cada hostname separadamente. exemplo.com e www.exemplo.com são endereços distintos no produto, mesmo que uma política HSTS no domínio base possa afetar a árvore no navegador.

Avalie preload separadamente

HSTS aprendido pela resposta tem uma lacuna na primeira visita: o navegador ainda precisa chegar ao host por HTTPS para memorizar a política. Preload tenta fechar essa lacuna colocando o domínio em uma lista distribuída com o navegador.

O custo é operacional. Para submissão, o serviço exige hoje certificado válido, redirect HTTP para HTTPS quando a porta 80 é usada, HTTPS em todos os subdomínios, includeSubDomains, preload e max-age de pelo menos um ano no domínio base.

Antes de solicitar inclusão, responda:

  • a organização controla todos os subdomínios atuais e futuros?
  • existe algum serviço interno ou legado que não suporta HTTPS?
  • a equipe aceita que remoção da lista depende de nova distribuição dos navegadores?
  • certificados e DNS possuem responsáveis e alertas?
  • o ganho adicional foi justificado pelo modelo de ameaça?

Se qualquer resposta estiver indefinida, pare no rollout normal de HSTS. Uma nota alta em scanner não compensa bloquear parte da organização.

Entregue o header na camada correta

HSTS só funciona como header HTTP recebido por transporte seguro. Uma meta tag http-equiv="Strict-Transport-Security" deve ser ignorada pelos navegadores conformes.

O contrato atual de Publicação do Site no Ar envia HTML e assets, mas não converte um arquivo _headers do pacote em políticas da resposta. Portanto, colocar esse arquivo na build não ativa HSTS.

Confirme uma camada autorizada que controle a resposta, como origem ou proxy administrado pela equipe ou suporte explícito da plataforma. Se essa camada não existir, registre HSTS como requisito pendente; não declare o domínio protegido.

Verifique a resposta publicada

Consulte cada hostname por HTTPS:

Terminal window
curl -sS -D - -o /dev/null https://exemplo.com/ \
  | rg -i '^strict-transport-security:'

Repita em rotas que passam por redirects, páginas de erro e hostnames alternativos. Confirme:

  • uma única ocorrência do header;
  • max-age esperado;
  • presença ou ausência intencional de includeSubDomains;
  • header também nas respostas HTTPS de redirect relevantes;
  • certificado válido e cadeia completa;
  • ausência do header em respostas HTTP inseguras;
  • redirect HTTP apontando para o hostname HTTPS correto.

Uma resposta vista no curl prova o servidor naquele momento. Para validar comportamento do navegador, use um perfil de teste, navegue primeiro por HTTPS e depois tente uma URL http:// do mesmo host. Registre a versão e não misture cache de políticas antigas com o resultado da etapa atual.

Prepare rollback antes de ampliar

O mecanismo de remoção é:

Strict-Transport-Security: max-age=0

Ele também precisa chegar por HTTPS válido. Se o certificado estiver quebrado, o navegador não consegue receber a instrução que apagaria a política. Por isso, rollback de HSTS depende primeiro de restaurar transporte seguro.

Além disso:

  • remover includeSubDomains do header não apaga imediatamente políticas que já foram memorizadas;
  • subdomínios que emitiram sua própria política mantêm estado independente;
  • preload tem processo e prazo próprios de remoção;
  • usuários que não voltarem ao site conservarão o estado até a expiração local.

Mantenha acesso à camada de headers, renovação emergencial de certificado e contatos de DNS documentados antes de aumentar max-age.

Publique e repita a validação

Se a revisão exigir corrigir URLs, redirects ou arquivos, gere uma nova build e republique o mesmo Site. Preserve Site ID, slug e domínio para comparar o comportamento.

Use este registro:

Site ID:
versão publicada:
hostnames testados:
valor HSTS por hostname:
início e fim da etapa:
certificados verificados:
erros observados:
aprovação para ampliar:
plano de rollback:

Prompt copiável para o agente

Revise a adoção de HSTS deste site sem alterar a produção ainda.


Fonte e build: [caminhos]
URL padrão: [URL]
Domínios próprios: [lista]
Camada que controla headers: [origem, proxy ou plataforma]


- Inventarie domínio base, todos os subdomínios e responsáveis.
- Confirme HTTPS, certificados, redirects e serviços em cada hostname.
- Proponha um rollout de max-age curto para longo.
- Não adicione includeSubDomains sem cobrir toda a árvore.
- Trate preload como decisão separada e de longo prazo.
- Confirme que o header é entregue por HTTPS na resposta real.
- Não use meta tag nem presuma que _headers será interpretado.
- Entregue testes, métricas, aprovações e rollback antes de publicar.

Checklist final

  • domínio base e subdomínios foram inventariados;
  • todos os hostnames no escopo funcionam por HTTPS;
  • emissão e renovação de certificados têm responsáveis;
  • redirects preservam o hostname e a rota esperados;
  • max-age começou curto e foi ampliado com evidência;
  • includeSubDomains recebeu aprovação de todos os proprietários;
  • preload foi avaliado como decisão separada;
  • o header aparece uma única vez nas respostas HTTPS;
  • nenhuma meta tag ou _headers foi confundido com proteção ativa;
  • URL padrão e domínios próprios foram testados;
  • rollback e acesso emergencial estão documentados;
  • a versão publicada ficou ligada às evidências.

HSTS é uma promessa que o domínio faz ao navegador por um período. A configuração segura não nasce do maior max-age; nasce de provar que cada hostname consegue cumprir essa promessa antes de ampliar seu alcance.