Cabeçalhos de segurança, explicados
Um cabeçalho de segurança é uma única linha numa resposta HTTP que muda o que o navegador do visitante pode fazer com a sua página: executar scripts apenas de fontes nomeadas, nunca mais falar HTTP simples, recusar ser enquadrado, recusar adivinhar tipos de conteúdo. Nenhum deles precisa de código, de uma biblioteca ou de um reinício — e, no entanto, a maioria dos sites envia poucos ou nenhuns, e é por isso que a maioria tira F quando um scanner verifica. Este artigo percorre cabeçalho a cabeçalho o que cada um realmente impede, explica a epidemia de F e dá a ordem de correção que recupera mais proteção por hora de trabalho. Para ver o veredito do seu próprio site, execute primeiro a verificação de cabeçalhos de segurança e leia com os seus resultados abertos.
Os cabeçalhos são instruções para o navegador, não armadura do servidor
Comece pelo que um cabeçalho não é. Um cabeçalho de segurança não corrige a sua aplicação, não filtra o seu tráfego nem autentica ninguém. É uma declaração que o servidor junta a uma resposta, e o navegador — o navegador do visitante, na máquina do visitante — aplica-a a partir desse momento. Soa fraco até repararmos em quantos ataques são executados pelo navegador em nome do atacante: correr um script que alguém injetou num campo de comentários, carregar a sua página de início de sessão dentro de um frame invisível num site hostil, tratar um ficheiro de texto carregado como HTML porque o seu conteúdo parecia de script. Os cabeçalhos são a forma de o servidor dizer ao navegador, antecipadamente, quais desses movimentos nunca são legítimos neste site.
Também são defesa em profundidade, e devem ser lidos assim. As referências canónicas deste espaço são a documentação HTTP da MDN, que especifica a sintaxe e a semântica de cada cabeçalho, e o Projeto de Cabeçalhos Seguros da OWASP, cujos valores recomendados são apontados pela orientação de testes do Guia de Testes de Segurança Web da OWASP. Nenhuma das fontes promete que os cabeçalhos tornam um site seguro. Prometem algo mais estreito e verdadeiro: com os cabeçalhos definidos, classes inteiras de ataques executados pelo navegador deixam de funcionar mesmo quando um erro da aplicação dá ao atacante um ponto de apoio.
O que cada cabeçalho realmente impede
Content-Security-Policy impede que scripts injetados sejam executados. O XSS e os seus primos — um comentário guardado com um script, um script de skimming injetado através de uma etiqueta de terceiros comprometida — precisam que o navegador execute código que o site nunca pretendeu. Uma CSP é uma lista de permissões: script-src nomeia as origens de onde os scripts podem vir, e tudo o resto, incluindo scripts inline e qualquer coisa carregada do servidor de um atacante, é recusado. As suas formas fracas são famosas: uma política que contém 'unsafe-inline' deixa correr todos os scripts inline, incluindo o injetado, e é por isso que o verificador trata essa política como fraca e não como boa. A CSP é o cabeçalho mais pesado de implementar e o que mais impede.
Strict-Transport-Security impede o rebaixamento. Na primeira vez que um visitante escreve o seu domínio sem esquema, ou segue uma ligação http:// antiga, esse pedido atravessa a rede em claro, onde pode ser despojado, redirecionado ou lido — cookie de sessão incluído. O HSTS diz ao navegador: durante os próximos max-age segundos, reescreva cada URL http:// deste anfitrião para https:// antes de qualquer coisa sair da máquina, e recuse cliques que ignoram erros de certificado. Um limite honesto: o HSTS só protege visitantes cujos navegadores já viram o cabeçalho uma vez (as listas de pré-carregamento integradas nos navegadores existem para fechar exatamente essa falha da primeira visita), e só é honrado quando ele próprio chega por HTTPS.
A proteção contra frames impede o clickjacking. Se as suas páginas puderem ser embutidas num frame, um site hostil pode estender a sua interface real sob uma camada transparente de botões próprios e colher os cliques: a vítima vê uma página inofensiva e aprova uma transferência. A diretiva da CSP frame-ancestors (e a sua irmã mais velha, X-Frame-Options: DENY ou SAMEORIGIN) nomeia quem pode enquadrá-lo; todos os outros recebem um frame vazio. X-Content-Type-Options: nosniff impede um truque mais silencioso: os navegadores historicamente adivinhavam o Content-Type declarado e executavam ficheiros como scripts ou HTML quando o conteúdo o parecia, transformando um carregamento inocente em XSS guardado. O nosniff acaba com as adivinhações — o tipo declarado é o tipo.
Referrer-Policy impede a fuga de URL. Quando um visitante clica da sua página para outro site, o navegador enviava historicamente o URL completo da sua página como Referer — incluindo quaisquer tokens de reposição de palavra-passe, termos de pesquisa ou identificadores de registo que levasse dentro. Uma política de strict-origin-when-cross-origin ou mais estrita envia apenas a origem entre sites e nada para destinos http propensos a rebaixamento. Permissions-Policy impede o abuso de funcionalidades: declara que capacidades poderosas do navegador — câmara, microfone, geolocalização, processadores de pagamento — este site pode usar de todo, para que um frame ou script injetado não possa pedi-las em silêncio em seu nome. E o cabeçalho bónus, Cross-Origin-Opener-Policy, corta a ligação window.opener entre a sua página e os popups de outras origens, isolando o seu contexto de navegação das páginas que o possam sondar.
Porque é que tantos sites tiram F
Porque a configuração por omissão de ninguém envia estes cabeçalhos. Um servidor web de fábrica, um andaime de framework de fábrica, um alojamento estático de fábrica: cada um envia respostas com, no máximo, um ou dois dos seis, e os dois mais valiosos — CSP e Permissions-Policy — exigem decisões sobre o site concreto, por isso nenhuma configuração por omissão os pode enviar com segurança. A responsabilidade parte-se então em três: a equipa da framework presume que o servidor junta cabeçalhos, a equipa do servidor presume que a framework o faz, e o CDN à frente reescreve o que lhe apetece de qualquer maneira. Os cabeçalhos caem pela fenda, em silêncio, porque sem eles nada parte de forma visível. Um site com F costuma parecer e funcionar exatamente como um com A; a diferença só aparece no dia em que um ataque precisa da cooperação do navegador.
Os números publicados coincidem com essa história. A amostra publicada de um scanner, relatada no resumo semanal de ferramentas de 2026-11-04, encontrou 65% dos sites analisados com nota F e 51% sem enviar qualquer Content-Security-Policy. Trate-os como o que são — a amostra de um scanner, publicada por terceiros, não uma medição de toda a web nem dados nossos —, mas a direção é corroborada pela experiência de qualquer operador: os cabeçalhos são aquele raro controlo de segurança cuja ausência é a norma estatística. E essa é também a boa notícia escondida na estatística: a fasquia está no chão, e subi-la é configuração, não engenharia.
Ordem de correção, por impacto por hora
Trabalhe pela ordem que a verificação de cabeçalhos de segurança torna óbvia. Primeiro, os de uma linha: X-Content-Type-Options: nosniff, a proteção contra frames e uma Referrer-Policy sensata — trinta e cinco dos cem pontos, uns minutos de trabalho e risco de quebra praticamente nulo num site normal. Segundo, HSTS — mais vinte pontos — mas só depois de verificar que cada página, subdomínio e redirecionamento herdado funciona genuinamente por HTTPS, porque um max-age longo não se pode desenviar. Terceiro, Permissions-Policy: liste as funcionalidades que o seu site realmente usa e desligue o resto; dez pontos por uma linha cuidadosa.
Por último, e devagar, a CSP. Os seus 35 pontos são o maior bloco individual e a única correção que pode deitar abaixo o seu próprio site. Implemente-a primeiro como Content-Security-Policy-Report-Only com um endpoint de relatórios, leia uma semana de violações, reescreva os scripts inline e os processadores de eventos que ela assinalar — ou adote nonces, como recomenda a orientação da MDN — e mude para aplicação forçada só quando os relatórios se calarem. Junte Cross-Origin-Opener-Policy: same-origin sempre que não depender de fluxos de popup entre origens; na nossa tabela não pontua, mas é um isolamento barato. Depois volte a executar a verificação e confirme que os cabeçalhos que juntou na origem sobreviveram realmente ao CDN e aos proxies à frente dele.
O que os cabeçalhos não podem fazer
Não podem corrigir o buraco, apenas encolher o que um atacante pode fazer através dele. Uma CSP não repara o campo de comentários que falhou a escapar a sua entrada; faz com que a carga injetada se recuse a correr. O HSTS não repara uma cadeia de certificados partida — esse é o território do avaliador SSL — e nenhum cabeçalho substitui correções, cópias de segurança ou controlo de acesso. Leia uma nota perfeita em cabeçalhos como uma porta bem trancada num edifício cujos outros pisos ainda precisam das suas próprias verificações, que é para o que serve a verificação de saúde do site.
Também não podem ser definidos e esquecidos. Uma CSP escrita para o site do ano passado bloqueia em silêncio o widget de pagamento deste ano — ou pior, é afrouxada com um * à pressa e deixa de significar o que quer que seja. Trate o conjunto de cabeçalhos como o resto da sua configuração: versionado, revisto quando o site muda e reverificado após cada mudança de plataforma. A verificação demora dez segundos; execute-a sempre que a pilha à frente das suas páginas mudar, e a epidemia de F continuará a ser a estatística de outra pessoa.