X-Content-Type-Options é um cabeçalho de resposta HTTP que tem exatamente um valor válido: nosniff. Ele instrui o navegador a seguir estritamente o MIME type declarado no cabeçalho Content-Type e jamais tentar adivinhar o tipo de conteúdo por conta própria. Isso previne uma categoria de ataques que exploram o comportamento de sniffing de MIME type dos navegadores.
De todos os cabeçalhos de segurança, o X-Content-Type-Options é o mais simples de entender e implementar. Ocupa uma linha de configuração, não tem diretivas complexas e essencialmente não há razão para não usá-lo. Ainda assim, um número surpreendente de sites continua sem enviá-lo.
O que é sniffing de MIME type e por que os navegadores o fazem
Para entender por que esse cabeçalho existe, é preciso um pouco de história. Nos primeiros dias da web, muitos servidores eram mal configurados e enviavam cabeçalhos Content-Type incorretos. Um servidor podia entregar um arquivo HTML como text/plain, ou uma imagem como application/octet-stream. Se os navegadores tivessem seguido estritamente o tipo declarado, essas páginas teriam sido renderizadas como texto bruto ou disparado um download em vez de exibir corretamente.
Para contornar isso, os navegadores começaram a "sniffar" o conteúdo real dos arquivos para determinar o tipo verdadeiro. O navegador olhava os primeiros bytes da resposta, verificava assinaturas conhecidas (como tags <html>, cabeçalhos de imagem ou padrões de JavaScript) e sobrescrevia o tipo declarado pelo servidor se o conteúdo parecesse diferente. O Internet Explorer era especialmente agressivo nisso. Se o IE detectasse algo parecido com HTML ou JavaScript dentro de um arquivo servido como text/plain, ele felizmente o renderizava ou executava.
Era uma solução razoável para servidores mal configurados, mas criou uma brecha séria de segurança.
Como o sniffing de MIME viabiliza ataques
Aqui está um cenário concreto de ataque que mira um site WordPress com upload de arquivos:
Suponha que seu site WordPress permita que usuários enviem fotos de perfil. Seu manipulador de upload verifica a extensão do arquivo e só permite .jpg, .png e .gif. Um atacante cria um arquivo que começa com cabeçalhos válidos de imagem (os primeiros bytes parecem um JPEG legítimo), mas contém código JavaScript embutido após o cabeçalho da imagem. Ele dá o nome de avatar.jpg e envia.
Seu servidor armazena o arquivo e o serve com Content-Type: image/jpeg. Até aqui, tudo parece correto. Mas então o atacante referencia esse arquivo a partir de uma página, talvez em um post de fórum ou em um comentário, usando uma tag de script:
<script src="https://yoursite.com/uploads/avatar.jpg"></script>Sem o X-Content-Type-Options, um navegador que faça sniffing de MIME pode olhar o arquivo, notar que ele contém conteúdo parecido com JavaScript e executá-lo como script, apesar do tipo de conteúdo image/jpeg. O JavaScript do atacante então roda no contexto do seu site, com acesso aos cookies e dados de sessão dos seus visitantes.
Com o cabeçalho nosniff, o navegador respeita o tipo declarado image/jpeg e se recusa a executar o arquivo como JavaScript. O ataque falha.
Sniffing de MIME e uploads de mídia no WordPress
O WordPress tem um sistema de upload de mídia que lida com muitos arquivos: imagens, PDFs, documentos, áudio, vídeo. Cada um deles é servido com um MIME type específico. O núcleo do WordPress já faz alguma validação nos uploads (conferindo tipos de arquivo contra uma lista permitida, verificando se o conteúdo do arquivo bate com a extensão), mas essas verificações não são infalíveis.
Vários fatores tornam o WordPress particularmente relevante aqui:
- Múltiplos pontos de upload: a biblioteca de mídia, Gravity Forms, Contact Form 7, imagens de produto do WooCommerce, anexos de fórum do bbPress e muitos outros plugins lidam com uploads de arquivos. Cada um deles é um ponto potencial de entrada para arquivos maliciosos.
- Conteúdo gerado pelo usuário: em sites com recursos de associação ou comunidade, você pode permitir que usuários relativamente não confiáveis enviem arquivos. Quanto mais fontes de upload você tiver, mais importante é que o navegador trate os arquivos exatamente como declarados.
- Manipuladores de upload de plugins: nem todos os plugins validam uploads tão cuidadosamente quanto o núcleo do WordPress. Um plugin mal escrito pode aceitar arquivos com tipos incompatíveis, criando exatamente as condições que ataques de sniffing de MIME exploram.
- Ambientes de hospedagem compartilhada: em hospedagem compartilhada, arquivos de outros sites no mesmo servidor podem, potencialmente, ser servidos com cabeçalhos incorretos. A diretiva
nosniffadiciona uma camada de defesa independentemente da qualidade da configuração do lado do servidor.
O cabeçalho de segurança mais simples de implementar
Adicionar X-Content-Type-Options leva uma linha. Não há diretivas para escolher, valores para ajustar ou risco de quebrar funcionalidades. Diferente do CSP (que pode quebrar scripts inline), do HSTS (que pode te trancar para fora se o certificado expirar) ou do Referrer-Policy (que pode afetar analytics), o X-Content-Type-Options tem efetivamente desvantagem zero.
Para Apache (.htaccess ou config do virtual host):
Header always set X-Content-Type-Options "nosniff"Para nginx:
add_header X-Content-Type-Options "nosniff" always;Via PHP no WordPress:
add_action('send_headers', function() {
header('X-Content-Type-Options: nosniff');
});O próprio WordPress já envia X-Content-Type-Options: nosniff para páginas administrativas e respostas da REST API desde a versão 4.8. Entretanto, as páginas de front-end da maioria das instalações WordPress não incluem esse cabeçalho, a menos que você o adicione no nível do servidor ou via plugin de segurança.
Como navegadores modernos lidam com sniffing de MIME
O comportamento dos navegadores melhorou significativamente ao longo dos anos. Versões modernas do Chrome, Firefox, Safari e Edge são muito menos agressivas em relação ao sniffing de MIME do que os navegadores da era do Internet Explorer. O Chrome, por exemplo, já bloqueia scripts que tenham um MIME type não-script em muitas situações, mesmo sem o cabeçalho nosniff.
No entanto, ainda existem casos limítrofes em que o sniffing ocorre, e navegadores antigos ainda podem ser vulneráveis. O cabeçalho nosniff fornece uma instrução clara e definitiva que remove qualquer ambiguidade. É uma boa prática independentemente de quais navegadores seus visitantes usam.
Interação com outros cabeçalhos de segurança
O X-Content-Type-Options funciona bem ao lado de outros cabeçalhos de segurança e não há conflitos com que se preocupar:
- Combinado com o CSP, ele oferece defesa em profundidade: o CSP controla quais fontes são permitidas, enquanto
nosniffgarante que arquivos das fontes permitidas sejam tratados conforme o tipo declarado. - Com HSTS, você garante conexões criptografadas, e com
nosniff, garante a integridade do conteúdo por cima disso. - Diferente de outros cabeçalhos, o
nosniffnão interage nem sobrescreve nenhum outro cabeçalho. Ele é puramente aditivo.
O que o InspectWP verifica
O InspectWP verifica se o seu site WordPress envia o cabeçalho X-Content-Type-Options: nosniff. Como esse cabeçalho tem apenas um valor válido e nenhuma complexidade de configuração, realmente não há motivo para que esteja ausente. Se o seu site não tem esse cabeçalho, é uma das vitórias de segurança mais rápidas que você pode obter. Adicioná-lo leva menos de um minuto e oferece proteção significativa contra ataques de confusão de MIME type, especialmente em sites que lidam com upload de arquivos.