O X-XSS-Protection é um cabeçalho HTTP que ativa a filtragem de XSS integrada em alguns navegadores. Embora os navegadores modernos dependam mais da Content Security Policy, esse cabeçalho oferece uma camada adicional de proteção para navegadores mais antigos. Ele pode ser configurado para bloquear ou sanitizar as tentativas de XSS detectadas.
O X-XSS-Protection é um cabeçalho de resposta legado que controlava o auditor de XSS embutido antes presente no Internet Explorer, no Edge e nos navegadores baseados em Chromium. Os valores iam de 0 (desativar o filtro), passando por 1 (ativar e sanitizar o conteúdo sinalizado), até 1; mode=block (ativar e bloquear a página inteira ao detectar). O filtro tentava identificar scripts refletidos, código que aparece tanto na requisição quanto na resposta, e neutralizá-lo antes que fosse executado. Os navegadores modernos removeram esse filtro por completo: o Chrome, o Edge e o Safari não agem mais com base no cabeçalho, e ele nunca existiu no Firefox. Hoje é considerado obsoleto, substituído pela Content Security Policy.
O cabeçalho importava historicamente porque oferecia alguma mitigação de XSS refletido para navegadores anteriores a uma Content Security Policy madura. Na prática, os filtros se mostraram pouco confiáveis e, pior, introduziram suas próprias vulnerabilidades: o modo de sanitização podia ser abusado para desativar seletivamente scripts legítimos, e pesquisadores encontraram canais laterais de vazamento de informações e XSS universal criados pelo próprio auditor. É por isso que os fornecedores o descontinuaram e removeram. Hoje, enviar 1; mode=block é, na melhor das hipóteses, inócuo e, na pior, reativa um comportamento problemático em um navegador antigo. As orientações atuais recomendam omitir o cabeçalho ou enviar explicitamente 0, e confiar em uma CSP forte e na codificação de saída em vez disso.
Não dependa do X-XSS-Protection. Defina-o como 0 ou deixe-o desativado, e concentre seu esforço nos controles que realmente impedem o XSS hoje: codificação de saída sensível ao contexto, validação de entrada, sanitização de DOM para qualquer HTML que você inserir, cookies HttpOnly para que tokens roubados sejam mais difíceis de alcançar, e uma Content Security Policy estrita e baseada em nonce. Quando o risco de XSS vem de JavaScript third-party ou injetado, e não dos seus próprios templates, a cside adiciona uma camada complementar, roteando scripts third-party por meio de um método Script, analisando o payload e bloqueando comportamentos maliciosos em tempo real enquanto mantém um registro forense, nada do que o cabeçalho descontinuado jamais forneceu.
Nenhum navegador atual age com base nele; o Chrome, o Edge e o Safari removeram o filtro e o Firefox nunca o teve. A maioria das orientações recomenda omitir o cabeçalho ou enviar 0, e então confiar em uma Content Security Policy forte e na codificação de saída. Enviar 1; mode=block não faz nada útil e pode acionar um comportamento antigo e problemático.
Os auditores capturavam apenas XSS refletido simples enquanto repetidamente criavam novos problemas, incluindo formas de desativar scripts específicos e bugs de cross-site-scripting universal ou de vazamento de informações. Corrigi-los de forma confiável se mostrou impraticável, e a Content Security Policy oferecia uma alternativa padronizada e muito mais forte, então os fornecedores optaram por remover o filtro por completo.
We answer client-side security questions every day. Bring yours.