Como configurar HSTS sem ficar bloqueado

HSTS é simples até deixar de ser

HTTP Strict Transport Security, normalmente abreviado para HSTS, diz aos navegadores: “para este site, usa sempre HTTPS.” Assim que um navegador recebe o cabeçalho através de uma ligação HTTPS válida, memoriza a regra durante o período que especificar.

Isso é útil. Impede ataques de downgrade de protocolo, reduz pedidos inseguros acidentais e evita o momento embaraçoso em que um utilizador escreve example.com e passa brevemente por HTTP em claro antes de ser redirecionado.

Também é persistente. Se publicar a política HSTS errada, os navegadores podem continuar a aplicá-la muito depois de remover o cabeçalho do servidor. É assim que as equipas ficam bloqueadas: não exatamente no seu próprio painel de administração, mas nos navegadores dos utilizadores, em subdomínios, sistemas de staging, endpoints legados e serviços esquecidos que não estão prontos para HTTPS obrigatório.

O objetivo não é evitar HSTS. O objetivo é implementá-lo como uma migração, não como um interruptor.

O que o cabeçalho HSTS faz realmente

Um cabeçalho HSTS típico tem este aspeto:

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

Tem três partes importantes:

• max-age: durante quanto tempo, em segundos, o navegador deve aplicar HTTPS para este host.
• includeSubDomains: se a regra também se aplica a todos os subdomínios.
• preload: um sinal de que quer que o domínio seja incluído nas listas de preload dos navegadores.

O navegador só confia neste cabeçalho quando o recebe através de HTTPS válido. Se o certificado for inválido, estiver expirado ou não corresponder, o navegador não deve aceitar uma nova política HSTS dessa resposta.

Depois de a política ficar guardada, tentativas futuras de visitar http://example.com são atualizadas pelo navegador para https://example.com antes de o pedido ser enviado. Esse é o ganho de privacidade: o pedido inseguro nunca sai do dispositivo.

Os cenários de bloqueio a evitar

A maioria das falhas de HSTS não é causada pelo site principal. Acontece nas extremidades.

1. Um subdomínio esquecido não está pronto para HTTPS

includeSubDomains parece organizado, mas é absoluto. Se o definir em example.com, aplica-se a:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• qualquer outro elemento sob esse domínio

Se algum desses hosts não conseguir servir HTTPS válido, os utilizadores com a política HSTS em cache não conseguirão aceder-lhes por HTTP.

2. Um certificado expira

Sem HSTS, por vezes os utilizadores avançam apesar dos avisos de certificado. Isso não é uma boa prática de segurança, mas acontece.

Com HSTS, os navegadores modernos não permitem contornar facilmente erros de certificado para esse host. Esse é o objetivo. Também significa que a renovação de certificados tem de ser aborrecida, monitorizada e testada.

3. Ferramentas de staging ou internas vivem sob o domínio de produção

Colocar ferramentas internas sob *.example.com pode tornar-se doloroso quando o domínio pai usa includeSubDomains. Se essas ferramentas usarem certificados autoassinados, autoridades de certificação privadas, configurações TLS antigas ou nenhum HTTPS, o HSTS vai expor o atalho.

Esta é uma razão pela qual muitas equipas mantêm sistemas internos e experimentais sob um domínio separado, com a sua própria política de segurança.

4. Preload é tratado como uma checkbox de rotina

HSTS preload não é apenas mais uma diretiva. Significa que o seu domínio pode ser distribuído dentro dos navegadores como apenas HTTPS antes de qualquer utilizador ter visitado o seu site.

Isto fecha a lacuna da “primeira visita”, mas é muito mais difícil de desfazer. A remoção das listas de preload pode demorar semanas ou meses a chegar aos utilizadores, dependendo dos ciclos de lançamento dos navegadores. Preload é adequado para domínios estáveis e maduros. Não é adequado para um site que ainda está a descobrir o seu inventário de subdomínios.

Um plano de implementação seguro

Step 1: Audite todos os hostnames que controla

Antes de definir includeSubDomains, liste todos os hostnames sob o domínio. Os registos DNS são um começo, mas não a história completa. Verifique configurações de CDN, painéis de alojamento, hostnames relacionados com email, ferramentas de marketing antigas, buckets de armazenamento e documentação interna.

Para cada hostname, responda:

• Serve HTTP, HTTPS ou ambos?
• O certificado HTTPS é válido e renovado automaticamente?
• Redireciona HTTP para HTTPS de forma limpa?
• Deve ser público?
• Ainda é necessário?

Se a sua equipa já tem hábitos de depuração de cabeçalhos em produção, isto encaixa naturalmente ao lado das verificações de redirecionamentos e cabeçalhos. Cobrimos esse fluxo de trabalho em um pequeno toolkit para depurar redirecionamentos e cabeçalhos HTTP em produção.

Step 2: Corrija HTTPS antes de adicionar HSTS

HSTS não torna segura uma configuração HTTPS avariada. Apenas torna HTTPS obrigatório.

Antes de o ativar, verifique:

• Os certificados TLS cobrem os hostnames corretos.
• Os certificados renovam automaticamente.
• HTTP redireciona para HTTPS com um único salto limpo sempre que possível.
• Os redirecionamentos do host canónico são consistentes, por exemplo de sem www para www, ou o inverso.
• Os assets da aplicação não dependem de URLs http:// inseguros.

Conteúdo misto é menos comum do que costumava ser, mas ainda aparece em temas CMS antigos, snippets de analytics, media incorporados e caminhos de imagens codificados diretamente.

Step 3: Comece com um max-age muito curto

Não comece com um ano. Comece com cinco minutos:

Strict-Transport-Security: max-age=300

Implemente isso apenas no hostname que está a testar, normalmente o site de produção canónico. Deixe includeSubDomains de fora por agora.

Depois teste em navegadores reais e com pedidos de linha de comandos:

curl -I https://example.com

Deve ver exatamente um cabeçalho Strict-Transport-Security. Cabeçalhos HSTS duplicados de um servidor de aplicação e de uma CDN são uma fonte comum de confusão. Os navegadores geralmente aplicam a política efetiva, mas humanos a depurar um incidente não precisam de ambiguidade.

Step 4: Aumente gradualmente

Se nada falhar, aumente a duração por fases:

Strict-Transport-Security: max-age=86400

Depois:

Strict-Transport-Security: max-age=604800

Depois talvez:

Strict-Transport-Security: max-age=2592000

Um calendário prático é:

• 5 minutos
• 1 dia
• 1 semana
• 1 mês
• 6 meses ou 1 ano

Não há prémio por acelerar. O objetivo de uma implementação faseada é dar tempo à monitorização, à caixa de entrada do suporte e aos casos de periferia para lhe dizerem o que a checklist deixou passar.

Step 5: Adicione includeSubDomains apenas depois de a auditoria ser real

Quando todos os subdomínios públicos estiverem prontos para HTTPS, pode considerar:

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

Este é o momento para ser conservador. Se um serviço legado ainda precisa de HTTP, não adicione includeSubDomains ao domínio pai. Migre esse serviço, mova-o para outro domínio ou aceite que a sua política HSTS deve permanecer mais estreita por agora.

Os cabeçalhos de segurança devem refletir a realidade. Não devem ser usados como cartazes motivacionais para a infraestrutura que espera ter mais tarde.

Step 6: Trate preload como um projeto separado

Considere preload apenas quando tudo isto for verdade:

• O domínio e todos os subdomínios suportam HTTPS válido.
• HTTP redireciona para HTTPS.
• O cabeçalho HSTS usa max-age de pelo menos 31536000 segundos.
• O cabeçalho inclui includeSubDomains.
• O cabeçalho inclui preload.
• Tem confiança de que não vai precisar de HTTP em claro em nenhum ponto sob o domínio.

Um cabeçalho pronto para preload tem este aspeto:

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

Submeter para a lista de preload é um compromisso de longo prazo. Se o site for um microsite de campanha, um domínio temporário de produto ou um domínio com fronteiras de propriedade pouco claras, ignore-o.

Exemplos de configuração

Nginx

Use always para que o cabeçalho também seja enviado em respostas de erro:

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

Depois de a implementação estar estável:

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

Apache

Com mod_headers ativado:

Header always set Strict-Transport-Security "max-age=300"

Mais tarde:

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

CDN ou plataforma de edge

Se a sua CDN define cabeçalhos de resposta, prefira gerir HSTS num só local. Não defina uma política na origem e outra no edge, a menos que tenha uma razão muito clara.

Verifique também se a CDN aplica cabeçalhos a redirecionamentos, erros em cache e páginas de erro personalizadas. Um site de produção não é apenas a sua resposta 200 OK.

Como desfazer HSTS em segurança

Se precisar de desativar HSTS, envie:

Strict-Transport-Security: max-age=0

Mas há uma armadilha: o navegador tem de conseguir aceder ao site por HTTPS válido para receber esse cabeçalho. Se o próprio HTTPS estiver avariado, os utilizadores com uma política HSTS em cache não conseguem obter a instrução que a limparia.

Por isso, a ordem habitual de recuperação é:

1. Restaurar HTTPS válido.
2. Servir Strict-Transport-Security: max-age=0.
3. Mantê-lo tempo suficiente para que utilizadores recorrentes o recebam.
4. Remover ou substituir o cabeçalho depois de o incidente estar resolvido.

Se o domínio estiver em preload, servir max-age=0 não basta para novos perfis de navegador. Também precisa de pedir a remoção da lista de preload e esperar que essa alteração seja distribuída através de atualizações dos navegadores.

Checklist de testes antes de publicar

Use esta checklist antes de aumentar max-age ou adicionar includeSubDomains:

• O URL HTTPS canónico devolve um certificado válido.
• HTTP redireciona para HTTPS.
• Há apenas um cabeçalho HSTS.
• O cabeçalho aparece em redirecionamentos e respostas de erro quando apropriado.
• Todos os subdomínios públicos têm HTTPS válido.
• A renovação de certificados é monitorizada.
• Nenhum sistema interno crítico depende de HTTP sob o mesmo domínio pai.
• Preload foi discutido explicitamente, não adicionado por hábito.

O Lighthouse também pode sinalizar cabeçalhos de segurança em falta ou fracos em alguns contextos, mas não deve ser o seu único método de verificação. Se o usar como parte de uma revisão mais ampla, leia os resultados como sinais e não como veredictos; a mesma mentalidade aplica-se quando lê um relatório Lighthouse sem entrar em pânico.

<!-- tool-cta:start -->

💡 Experimente isto: Antes e depois de cada alteração de HSTS, inspecione a resposta Strict-Transport-Security com Get Headers para confirmar que max-age, includeSubDomains e preload estão como você espera.

<!-- tool-cta:end -->

O argumento de privacidade a favor do HSTS

HSTS é frequentemente apresentado como um cabeçalho de segurança, e é. Também tem um benefício de privacidade: reduz a probabilidade de o primeiro pedido de um utilizador ser exposto por HTTP em claro numa rede não fidedigna.

Isso importa em Wi-Fi de aeroportos, redes de hotéis, redes corporativas para visitantes e em qualquer lugar onde o tráfego de um utilizador possa ser observado ou modificado. Um pedido HTTP em claro pode expor o hostname, o caminho, cookies sem a flag Secure e outros detalhes do pedido. HTTPS não é magia, mas forçá-lo de forma consistente remove uma classe inteira de fugas evitáveis.

As melhores implementações de HSTS são desinteressantes. São lançadas lentamente, apoiadas por certificados fiáveis e suficientemente aborrecidas para que ninguém repare. É exatamente isso que quer de um cabeçalho cujo modo de falha pode ser dramático.