Guias de Segurança
Como escolher os cabeçalhos de segurança: o que ainda é necessário, o que está obsoleto e o que faz mal
Muitas listas de cabeçalhos de segurança pararam de ser atualizadas e recomendam cabeçalhos que já saíram de uso. O MDN marca o X-XSS-Protection como obsoleto e não padrão, e alerta que ele pode criar vulnerabilidades de XSS em sites que seriam seguros. Quais cabeçalhos definir hoje e quais remover.
Exemplos de configuração de cabeçalhos estão por toda parte. O problema é que a maioria deles parou de ser atualizada. Copie uma lista que estava correta alguns anos atrás e você traz cabeçalhos que já perderam a função — e um que pode fazer mal ativamente.
① Os seis que vale a pena definir hoje
O nosso verificador de cabeçalhos de segurança avalia estes seis. Os cabeçalhos obsoletos ficam de fora de propósito.
- Content-Security-Policy
- Declara de onde scripts e recursos podem vir. O controle central que reduz o que um XSS consegue fazer. A diretiva
frame-ancestorstambém controla a incorporação em frames - Strict-Transport-Security
- Diz ao navegador para sempre voltar por HTTPS, fechando a primeira requisição em texto puro (
max-agemaisincludeSubDomains) - X-Frame-Options
- Recusa a exibição em frames por outros sites — defesa contra clickjacking. Na prática é definido junto com o
frame-ancestorsdo CSP - X-Content-Type-Options
nosniff. Impede o navegador de adivinhar um tipo a partir do conteúdo, o que reduz incidentes em que um arquivo enviado é interpretado como algo que não deveria- Referrer-Policy
- Limita o referenciador repassado adiante, reduzindo o vazamento do que quer que tenha ido parar numa URL (partindo do princípio de que você nunca coloca segredos ali)
- Permissions-Policy
- Desativa por padrão recursos do navegador — câmera, microfone, geolocalização. Feche o que você não usa
A ordem importa: comece pelo que não pode quebrar nada
X-Content-Type-Options, X-Frame-Options, Referrer-Policy e Permissions-Policy são confiáveis e dificilmente quebram a renderização, então podem entrar primeiro. O Strict-Transport-Security deve esperar até o HTTPS funcionar em todos os caminhos — ele fica memorizado no navegador, o que torna difícil voltar atrás.
O CSP vem por último, e aos poucos. Ele afeta mais funcionalidades, e endurecê-lo de uma vez vai quebrar funções legítimas. Monte-o com o gerador de CSP.
② O que já perdeu a função
Expect-CT: praticamente obsoleto desde junho de 2021
O MDN marca este cabeçalho como Deprecated e explica que só o Google Chrome e outros navegadores baseados em Chromium o implementaram, e que o Chromium tornou o cabeçalho obsoleto a partir da versão 107, porque agora aplica o CT por padrão. Uma nota na mesma página acrescenta que "o Expect-CT está praticamente obsoleto desde junho de 2021".
Ou seja, o navegador passou a fazer isso por padrão, então não sobrou nada para o site instruir. Não há motivo para adicioná-lo a nada novo.
③ O que hoje pode fazer mal
X-XSS-Protection: obsoleto, não padrão e capaz de criar XSS
O MDN exibe os avisos Deprecated e Non-standard neste cabeçalho, além de um alerta: "Embora este recurso possa proteger usuários de navegadores antigos que não suportam CSP, em alguns casos o X-XSS-Protection pode criar vulnerabilidades de XSS em sites que seriam seguros."
A recomendação não deixa dúvida: "Recomenda-se usar Content-Security-Policy em vez de filtragem de XSS."
Este é o caso decisivo contra "mais cabeçalhos é melhor". Uma configuração adicionada de boa-fé pode, nas circunstâncias certas, virar a superfície de ataque. Se você não o envia, não o adicione; se já envia, planeje removê-lo. Para a falha de fundo, veja o que é XSS.
Como é uma lista desatualizada
CSP, HSTS, X-Frame-Options e nosniff — e mais
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …
É uma lista mais longa, e alguns verificadores podem até dar uma nota maior a ela. Diante dos navegadores atuais, porém, essas entradas extras são inócuas ou capazes de causar dano.
Como é a prática hoje
O CSP no centro, os outros cinco dando apoio.
Cabeçalhos obsoletos não são adicionados e são removidos onde existirem. O esforço gasto na qualidade do CSP — especificamente em quanto do 'unsafe-inline' você eliminou — rende muito mais defesa real do que aumentar a lista.
A premissa: os cabeçalhos não corrigem a vulnerabilidade em si
Defeitos da aplicação (XSS, falta de autorização, uploads)
nenhuma quantidade de cabeçalhos elimina isso
↓ quando um ocorre
O que os cabeçalhos controlam
para onde os dados podem ser enviados · se a página pode ser exibida em frame · se texto puro é permitido = limitar a propagação
Adicionar CSP a um site com uma falha de XSS não elimina o XSS; reduz o que pode ser feito com ele. Então a ordem é: corrigir o defeito da aplicação e depois acrescentar os cabeçalhos como mais uma linha. E o inverso também vale — uma nota perfeita de cabeçalhos não é prova de um site seguro.
Verificando o seu próprio site
Meça o que está de fato sendo retornado
Leia as respostas, não os arquivos de configuração. Proxies reversos, CDNs, frameworks e a própria aplicação adicionam ou sobrescrevem cabeçalhos, então o que está configurado e o que é enviado nem sempre são a mesma coisa. O nosso verificador de cabeçalhos mede uma URL diretamente.
Procure cabeçalhos obsoletos na resposta
Se X-XSS-Protection ou Expect-CT aparecerem, planeje removê-los. Principalmente o primeiro — como visto acima, ele está documentado como capaz de criar uma vulnerabilidade.
Adicione os quatro que não podem quebrar nada
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin e um Permissions-Policy fechando os recursos que você não usa. Confiáveis e com pouca chance de afetar a renderização.
Deixe o HSTS para quando o HTTPS estiver funcionando por completo
O Strict-Transport-Security é memorizado pelo navegador, então ativá-lo enquanto o HTTPS ainda está instável torna a recuperação penosa. Confirme primeiro que todos os caminhos servem HTTPS. O básico sobre certificados está em o que é o Let's Encrypt.
Introduza o CSP aos poucos e vá endurecendo
Comece permissivo e vá apertando, tendo como objetivo remover o 'unsafe-inline' — até onde você chega nisso decide em grande parte quanta proteção o CSP oferece. Monte-o com o gerador de CSP e aproveite para revisar o restante de a checklist de base de segurança.
A visão deste site: em configuração copiada, a idade da fonte decide o quanto ela é segura
Cabeçalhos de segurança são o exemplo típico de configuração copiada e colada, e é exatamente por isso que a idade da fonte determina o quanto o resultado é seguro. Os dois cabeçalhos deste artigo já estiveram corretos um dia. O X-XSS-Protection foi além: a recomendação da sua época é o alerta de hoje.
Nossa posição é tratar a configuração de cabeçalhos como uma configuração que você revisita de tempos em tempos, não uma tarefa que se conclui uma vez — e não mirar na nota de um verificador, já que uma nota pode subir com a adição de um cabeçalho obsoleto. Gaste o tempo na qualidade do seu CSP, e não no tamanho da lista.
Fontes (primárias)
- MDN Web Docs, "X-XSS-Protection" — developer.mozilla.org (os avisos Deprecated e Non-standard, o alerta de que pode criar vulnerabilidades de XSS em sites que seriam seguros e a recomendação de usar CSP em seu lugar)
- MDN Web Docs, "Expect-CT" — developer.mozilla.org (o aviso Deprecated, a descontinuação no Chromium 107 e o motivo, e a nota de que está praticamente obsoleto desde junho de 2021)
Ambos consultados em 5 de setembro de 2026.
Leia a seguir
- Ferramentas: verificador de cabeçalhos de segurança / gerador de CSP
- Glossário: o que é XSS / o que é clickjacking / o que é CORS
- Fundamentos: a checklist de base de segurança
FAQ
QDevo definir o X-XSS-Protection?
Não. O MDN marca este cabeçalho como Deprecated (obsoleto) e Non-standard (não padrão), e alerta que, embora ele possa proteger usuários de navegadores antigos que não suportam CSP, em alguns casos o X-XSS-Protection pode criar vulnerabilidades de XSS em sites que seriam seguros. A recomendação é explícita: use Content-Security-Policy em vez de filtragem de XSS. Se você não o envia, não o adicione; se envia, planeje removê-lo.
QO Expect-CT ainda é necessário?
Não. O MDN o marca como Deprecated e explica que só o Google Chrome e outros navegadores baseados em Chromium o implementaram, e que o Chromium tornou o cabeçalho obsoleto a partir da versão 107 porque agora aplica o Certificate Transparency por padrão. Uma nota na mesma página afirma que o cabeçalho está praticamente obsoleto desde junho de 2021. Não há motivo para adicioná-lo a nada novo.
QEntão quais devo definir?
Os seis que a nossa ferramenta de verificação de cabeçalhos avalia são um ponto de partida prático: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. Cabeçalhos obsoletos ficam de fora desse conjunto de propósito. Quanto à ordem, adicione primeiro os que são confiáveis e dificilmente quebram algo (nosniff, X-Frame-Options) e introduza o CSP aos poucos, porque ele afeta mais funcionalidades.
QSe eu definir todos os cabeçalhos, o site fica seguro?
Não. Os cabeçalhos não corrigem vulnerabilidades da sua aplicação; eles limitam até onde o dano se espalha. Adicionar CSP a um site com uma falha de XSS não elimina o XSS — reduz o que pode ser feito com ele. Corrija primeiro o defeito da aplicação e acrescente os cabeçalhos como mais uma linha de defesa. E o inverso: uma nota perfeita num verificador de cabeçalhos não é prova de que um site é seguro.