Cabeçalhos HTTP de segurança: quais ativar e porquê

Os cabeçalhos HTTP permitem ao servidor dar ao navegador instruções de segurança antes de a página estar totalmente interpretada. São poderosos, mas devem ser escolhidos de acordo com o comportamento real do site.

HSTS: impor HTTPS com prudência

Strict-Transport-Security pede ao navegador que utilize HTTPS durante um período definido. É adequado quando todo o site e os subdomínios abrangidos funcionam corretamente em HTTPS.

A configuração utiliza normalmente max-age. includeSubDomains estende a regra aos subdomínios, pelo que todos devem estar preparados para HTTPS. O preload representa um compromisso ainda maior e a remoção não é imediata. Durante a implementação, comece com uma duração prudente e aumente-a depois de verificar a infraestrutura.

Referrer-Policy: controlar a informação transmitida

Referrer-Policy determina que parte da URL de origem pode ser enviada numa navegação ou pedido. Uma política como strict-origin-when-cross-origin pode limitar a informação transmitida a outros sites, preservando mais contexto na mesma origem.

Nunca coloque segredos numa URL esperando que esta política os proteja: histórico, logs e outros intermediários podem já tê-los registado.

Permissions-Policy: limitar capacidades

Câmara, microfone, geolocalização e outras APIs poderosas não precisam de estar disponíveis em todo o lado. Permissions-Policy permite especificar que origens podem utilizar determinadas funcionalidades, incluindo dentro de iframes.

Isto é especialmente útil em integrações de terceiros: uma iframe necessária para mostrar um componente não precisa automaticamente de todas as capacidades do navegador.

Proteção contra framing

X-Frame-Options continua a ser utilizado para controlar integração em iframes, enquanto frame-ancestors numa CSP oferece um controlo moderno e mais flexível. Evite configurações contraditórias e teste as integrações realmente utilizadas.

X-Content-Type-Options: nosniff

Este cabeçalho pede ao navegador que respeite o tipo MIME declarado em determinados carregamentos em vez de tentar adivinhar outro. É uma proteção simples, desde que o servidor anuncie corretamente os seus conteúdos.

COOP, COEP e CORP

Estes cabeçalhos reforçam o isolamento entre contextos e recursos cross-origin. Podem ser necessários para algumas funcionalidades modernas, mas também impõem restrições a recursos de terceiros. Ativá-los apenas porque aparecem numa checklist pode quebrar a aplicação.

O melhor método é partir da necessidade funcional, compreender as consequências e verificar as respostas reais.

Confirmar o que o servidor envia realmente

Uma configuração escrita num ficheiro não protege nada se o cabeçalho não chegar à resposta final. Analise os cabeçalhos efetivamente recebidos em produção e confirme as rotas importantes.

Verifique também se uma proteção não impede uma funcionalidade necessária. Estes cabeçalhos complementam a Content Security Policy; não a substituem.

Construir um conjunto coerente

Uma base razoável combina frequentemente HTTPS, HSTS quando o domínio está preparado, nosniff, uma Referrer-Policy explícita e uma CSP adequada. Permissions-Policy e os mecanismos de isolamento são acrescentados de acordo com as funcionalidades reais.

O número de cabeçalhos não é uma pontuação de segurança. Uma configuração pequena, compreendida e testada é melhor do que uma longa lista copiada que quebra o site ou cria uma falsa sensação de proteção.