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.
GuiaBoas práticasIniciante
Cabeçalhos HTTP de segurança: quais ativar e porquê
Compreenda HSTS, Referrer-Policy, Permissions-Policy, proteções de framing e isolamento cross-origin antes de os implementar.
Mostrar índice
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.