O problema que o HSTS resolve
Servir um site em HTTPS é necessário, mas não basta. A brecha está na primeira requisição. O usuário digita example.com, o navegador tenta http://example.com e o servidor responde com um redirect para https://. Um atacante bem posicionado na rede pode interceptar essa primeira requisição em HTTP puro e remover o upgrade para HTTPS, ou se colocar no meio da conexão. O problema não está no site criptografado; o ponto fraco é o hop sem criptografia que vem antes dele.
O Strict-Transport-Security () diz ao navegador para nunca mais usar HTTP puro com este host. Depois que o navegador vê o header (o cabeçalho HTTP) uma vez, ele mesmo reescreve toda requisição http:// para https://, antes de qualquer coisa sair para a rede, durante todo o tempo de validade da política. A janela de downgrade se fecha.
Como ler o header
Um valor forte típico é assim:
strict-transport-security: max-age=63072000; includeSubDomains; preload
max-age é o tempo de vida da política, em segundos, e é a parte que mais importa. É por quanto tempo o navegador vai continuar forçando HTTPS para aquele host, contado a partir da última vez em que viu o header. Cada visita que traz o header reinicia a contagem. O valor acima corresponde a dois anos.
includeSubDomains estende a política a todos os subdomínios. Sem ele, example.com fica protegido, mas app.example.com não, e isso abre um caminho para o atacante mirar um subdomínio que nunca foi visitado diretamente.
preload é um pedido de inclusão na lista de preload dos navegadores, descrita mais abaixo.
Quanto tempo é suficiente
O analisador avalia o max-age por faixas. Um valor de um ano ou mais é a referência recomendada e é marcado como forte. Um valor abaixo de mais ou menos seis meses é sinalizado como baixo, porque, com uma validade curta, a proteção expira rápido para o usuário que não volta com frequência. Um max-age de 0 é um caso especial: ele não cria uma política curta; ele desativa o HSTS e manda o navegador esquecer qualquer política que já exista para aquele host. Esse só é o valor certo quando você está desligando o HSTS de propósito; fora isso, é um erro de configuração que acaba com a proteção por completo.
Confiança no primeiro uso e o que o preload resolve
O HSTS, do jeito descrito até aqui, ainda tem uma brecha: a primeira visita, antes de o navegador ter visto o header alguma vez, fica desprotegida. É a confiança no primeiro uso (trust on first use). Para a maioria dos sites, essa janela é de uma única requisição, e isso é aceitável. Para os sites que querem fechar essa janela por completo, a lista de preload dos navegadores resolve.
A lista de preload é um conjunto de hosts gravados no código dos navegadores como somente HTTPS; com isso, o navegador força HTTPS já na primeira requisição, sem precisar de nenhuma visita anterior. Para entrar na lista, o site serve uma política com max-age longo, includeSubDomains e a diretiva preload e, depois, submete o host à lista. Há dois cuidados importantes. O preload vale para o domínio inteiro e para todos os subdomínios, então cada um deles precisa conseguir servir HTTPS. E sair da lista é demorado, então um site só entra no preload quando tem certeza de que vai continuar somente em HTTPS por tempo indeterminado.
Erros de configuração que desativam o HSTS
As falhas que se repetem passam despercebidas, porque o header está lá, mas não está fazendo o trabalho dele. Um max-age de 0 esquecido depois de um teste desativa a política. Um max-age muito baixo deixa a política expirar entre uma visita e outra. Deixar de fora o includeSubDomains expõe os subdomínios. Servir a diretiva preload sem cumprir os requisitos do preload não causa dano, mas também não serve para nada. E, ponto importante, o HSTS só passa a valer depois que o navegador recebe o header por uma conexão HTTPS válida; por isso, ele precisa ir nas respostas seguras, e não ficar escondido em algum lugar que o navegador nunca acessa por HTTPS.
Onde o HSTS se encaixa na pilha
O HSTS elimina uma classe de ataque no nível do transporte: o downgrade forçado para HTTP puro. Ele combina naturalmente com a flag Secure nos cookies, que, para começo de conversa, impede que os cookies sigam em qualquer requisição em HTTP puro (veja flags de segurança de cookies), e com uma Content-Security-Policy, que controla o que roda depois que a página carrega. Nenhum desses mecanismos substitui os outros; juntos, eles cobrem transporte, sessão e conteúdo.