O que é HSTS (HTTP Strict Transport Security)?

HTTP Strict Transport Security (HSTS) é um mecanismo de segurança que instrui os navegadores a se comunicarem com seu site somente via HTTPS. Assim que um navegador recebe o cabeçalho HSTS do seu servidor, ele converte automaticamente qualquer requisição HTTP em HTTPS pelo período especificado no cabeçalho, mesmo que o usuário digite explicitamente http:// na barra de endereços ou clique em um link HTTP antigo.

Isso pode parecer apenas um pequeno recurso de conveniência, mas resolve um problema real e perigoso. Vamos entender exatamente por que o HSTS existe, como ele funciona na prática e o que você precisa saber como proprietário de um site WordPress.

Como os ataques de SSL stripping funcionam sem HSTS

Imagine que um visitante abre o notebook em uma cafeteria e digita seusite.com no navegador. Sem HSTS, o navegador envia primeiro uma requisição HTTP simples ao seu servidor. Seu servidor então responde com um redirecionamento 301 para https://seusite.com. Essa requisição HTTP inicial, no entanto, é totalmente não criptografada. Ela trafega pela rede WiFi da cafeteria como texto simples.

Um atacante na mesma rede pode interceptar essa primeira requisição não criptografada usando uma técnica chamada SSL stripping. O atacante atua como um proxy: mantém uma conexão HTTPS com seu servidor real, mas serve uma versão HTTP simples para a vítima. Da perspectiva do visitante, o site parece normal (a maioria das pessoas não verifica o ícone de cadeado). Enquanto isso, o atacante pode ler tudo: credenciais de login, envios de formulários, cookies de sessão, dados de cartão de crédito.

Esse não é um ataque teórico. Ferramentas como o sslstrip estão publicamente disponíveis desde 2009, e o SSL stripping continua sendo um dos ataques mais práticos em redes WiFi públicas. O HSTS existe especificamente para fechar essa brecha.

Como o HSTS protege seu site WordPress

Quando seu servidor envia o seguinte cabeçalho de resposta:

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

O navegador armazena essa instrução internamente. Pelos próximos 31.536.000 segundos (um ano), ele jamais tentará uma conexão HTTP com seu domínio. Se algo tentar carregar um recurso via HTTP, o navegador o reescreve para HTTPS localmente antes mesmo que a requisição saia do dispositivo. Não há requisição não criptografada para um atacante interceptar.

Essa proteção funciona no nível do navegador, e essa é a vantagem principal. Nenhum redirecionamento é necessário. Nenhuma requisição não criptografada é enviada. O navegador simplesmente se recusa a usar HTTP para o seu domínio.

Diretivas do cabeçalho HSTS explicadas

O cabeçalho HSTS aceita três diretivas, e cada uma tem uma finalidade específica:

• max-age: o tempo em segundos que o navegador deve lembrar de impor HTTPS. Valores comuns são 86400 (1 dia, útil para testes iniciais), 2592000 (30 dias, um bom ponto de partida) e 31536000 (1 ano, o valor recomendado para produção). Se você definir como zero, o navegador deixará imediatamente de aplicar HSTS para o seu domínio.
• includeSubDomains: estende a política HSTS a todos os subdomínios. Isso significa que cdn.seusite.com, mail.seusite.com e qualquer outro subdomínio também serão forçados a HTTPS. Tenha cuidado com essa diretiva: se algum subdomínio não suportar HTTPS, ele se tornará inacessível assim que ela for ativada.
• preload: um sinal de que você deseja que seu domínio seja adicionado às listas de preload dos navegadores. Mais sobre isso a seguir.

O problema da primeira visita e as listas HSTS Preload

O HSTS tem uma limitação fundamental: o navegador precisa receber o cabeçalho ao menos uma vez antes de poder aplicar qualquer regra. Na primeiríssima visita, antes do navegador ter visto seu cabeçalho HSTS, a requisição HTTP inicial ainda fica vulnerável à interceptação. Isso é conhecido como "problema da primeira visita" ou "problema de bootstrap".

A lista HSTS preload resolve isso. Ela é uma lista de domínios codificada diretamente no próprio navegador (Chrome, Firefox, Safari e Edge compartilham a mesma lista). Se o seu domínio estiver na lista de preload, o navegador impõe HTTPS desde a primeira conexão, mesmo que o usuário nunca tenha visitado seu site antes.

Para colocar seu domínio na lista de preload, você precisa cumprir todos os requisitos a seguir:

• Servir um certificado HTTPS válido no domínio raiz
• Redirecionar todo o tráfego HTTP para HTTPS no mesmo host
• Servir o cabeçalho HSTS no domínio raiz com max-age de pelo menos 31536000 (um ano)
• Incluir a diretiva includeSubDomains
• Incluir a diretiva preload
• Todos os subdomínios precisam suportar HTTPS

Você pode submeter seu domínio em hstspreload.org. Tenha em mente que entrar na lista leva semanas ou meses (a inclusão é distribuída junto com atualizações do navegador), e sair dela é igualmente lento. Garanta que sua configuração HTTPS esteja sólida antes de submeter.

Valores comuns de max-age e estratégia de rollout recomendada

É tentador pular direto para um max-age de um ano, mas um rollout gradual é mais seguro, especialmente para sites com múltiplos subdomínios ou configurações complexas:

• max-age=300 (5 minutos): use durante os testes iniciais. Se algo der errado, os visitantes ficarão presos ao HTTPS por apenas cinco minutos.
• max-age=86400 (1 dia): um bom próximo passo depois de confirmar que o HTTPS está funcionando corretamente.
• max-age=2592000 (30 dias): avance para esse valor após uma ou duas semanas de operação estável.
• max-age=31536000 (1 ano): o valor recomendado para produção. Esse também é o mínimo exigido para a lista de preload.

Configurando HSTS em um site WordPress

O WordPress por si só não envia o cabeçalho HSTS por padrão. Você tem várias opções para adicioná-lo:

A abordagem mais confiável é adicionar o cabeçalho no nível do servidor. No Apache, adicione isto ao seu arquivo .htaccess ou à configuração do virtual host:

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

Para nginx, adicione isto dentro do bloco server:

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

Se você não tem acesso à configuração do servidor (comum em hospedagem compartilhada), pode adicionar o cabeçalho via PHP no functions.php do seu tema ou por meio de um must-use plugin:

add_action('send_headers', function() {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
});

A abordagem no nível do servidor é preferível porque se aplica a todas as respostas, incluindo arquivos estáticos e páginas de erro, não apenas a páginas geradas pelo PHP.

Vários plugins de segurança do WordPress também oferecem configuração de HSTS por meio de seus painéis de ajustes, o que pode ser conveniente se você preferir uma abordagem com interface gráfica.

Armadilhas comuns do HSTS no WordPress

Antes de habilitar o HSTS, verifique algumas coisas:

• Conteúdo misto: certifique-se de que todos os recursos (imagens, scripts, folhas de estilo, fontes) sejam carregados via HTTPS. O HSTS força a conexão principal a usar HTTPS, mas se o seu conteúdo ainda referenciar URLs HTTP, os navegadores bloquearão esses recursos.
• Renovação do certificado SSL: uma vez que o HSTS esteja ativo, um certificado expirado tornará seu site totalmente inacessível (em vez de exibir um aviso que pode ser ignorado). Configure a renovação automática do certificado com Let's Encrypt ou seu provedor de certificados.
• Prontidão dos subdomínios: se você usar includeSubDomains, cada um dos subdomínios precisa de um certificado HTTPS válido. Um subdomínio de staging em HTTP deixará de funcionar.
• Configuração de CDN: se você usar uma CDN como o Cloudflare, garanta que o HSTS esteja configurado de forma consistente. O Cloudflare oferece suas próprias configurações de HSTS que podem sobrescrever os cabeçalhos do seu servidor.

O que o InspectWP verifica

O InspectWP analisa se o seu site WordPress envia o cabeçalho de resposta Strict-Transport-Security. O relatório avalia o valor de max-age, verifica a presença da diretiva includeSubDomains e marca o cabeçalho como ausente se ele não estiver presente. Um cabeçalho HSTS adequado, com um valor de max-age longo (pelo menos 6 meses ou um ano) e a diretiva includeSubDomains, é recomendado para todo site WordPress que rode em HTTPS — o que, na web atual, deveria ser o caso de todos eles.