X-Content-Type-Options è un response header HTTP con esattamente un valore valido: nosniff. Istruisce il browser a seguire rigorosamente il MIME type specificato nell'header Content-Type e a non tentare mai di indovinare il tipo di contenuto. Questo previene una categoria di attacchi che sfrutta il comportamento di MIME type sniffing dei browser.
Tra tutti gli header di sicurezza, X-Content-Type-Options è il più semplice da capire e implementare. Richiede una riga di configurazione, non ha direttive complesse e non c'è davvero motivo di non usarlo. Eppure, sorprendentemente molti siti ancora non lo inviano.
Cos'è il MIME type sniffing e perché i browser lo fanno
Per capire perché questo header esiste, aiuta un po' di storia. Agli albori del web, molti server erano configurati male e inviavano header Content-Type errati. Un server poteva servire un file HTML come text/plain, o un'immagine come application/octet-stream. Se i browser avessero seguito rigorosamente il tipo specificato, queste pagine sarebbero state mostrate come testo grezzo o avrebbero attivato un download invece di essere visualizzate correttamente.
Per aggirare questo, i browser iniziarono a "sniffare" il contenuto effettivo dei file per determinare il vero tipo. Il browser guardava i primi byte di una risposta, cercava firme conosciute (come tag <html>, intestazioni di immagine o pattern JavaScript) e sovrascriveva il tipo dichiarato dal server se il contenuto sembrava diverso. Internet Explorer era particolarmente aggressivo in questo. Se IE rilevava qualcosa che assomigliava a HTML o JavaScript in un file servito come text/plain, lo rendeva o lo eseguiva volentieri.
Era una soluzione ragionevole per server mal configurati, ma creava una grave falla di sicurezza.
Come lo sniffing MIME rende possibili gli attacchi
Ecco uno scenario di attacco concreto mirato a un sito WordPress con upload di file:
Supponi che il tuo sito WordPress permetta agli utenti di caricare immagini di profilo. Il tuo handler di upload controlla l'estensione del file e consente solo .jpg, .png e .gif. Un aggressore crea un file che inizia con header di immagine validi (i primi byte sembrano un JPEG corretto), ma che contiene codice JavaScript dopo l'header dell'immagine. Lo chiama avatar.jpg e lo carica.
Il tuo server salva il file e lo serve con Content-Type: image/jpeg. Finora sembra tutto a posto. Ma ora l'aggressore collega questo file da una pagina, ad esempio in un post di forum o commento, con un tag script:
<script src="https://tuosito.com/uploads/avatar.jpg"></script>Senza X-Content-Type-Options, un browser che applica MIME sniffing potrebbe guardare il file, notare che contiene contenuto simile a JavaScript ed eseguirlo come script nonostante il content-type image/jpeg. Il JavaScript dell'aggressore ora gira nel contesto del tuo sito, con accesso a cookie e dati di sessione dei tuoi visitatori.
Con l'header nosniff, il browser rispetta il tipo specificato image/jpeg e rifiuta di eseguire il file come JavaScript. L'attacco fallisce.
MIME sniffing e upload media WordPress
WordPress ha un sistema di upload media che gestisce molti tipi di file: immagini, PDF, documenti, audio e video. Ognuno di questi viene servito con un MIME type specifico. Il core di WordPress valida già parzialmente gli upload (controllando i tipi di file rispetto a una lista consentita e verificando che il contenuto corrisponda all'estensione), ma questi controlli non sono a prova di errore.
Diversi fattori rendono WordPress particolarmente rilevante qui:
- Molteplici punti di upload: la libreria media, Gravity Forms, Contact Form 7, immagini prodotto WooCommerce, allegati ai forum bbPress e molti altri plugin gestiscono tutti upload di file. Ognuno di questi è una potenziale porta d'ingresso per file malevoli.
- Contenuti generati dagli utenti: su siti con funzionalità di iscrizione o community, potresti permettere a utenti relativamente non fidati di caricare file. Più fonti di upload ci sono, più importante è che il browser tratti i file esattamente come specificato.
- Handler di upload di plugin: non tutti i plugin validano gli upload con la stessa attenzione del core WordPress. Un plugin scritto male può accettare file con tipi non corrispondenti e quindi creare esattamente le condizioni che gli attacchi di MIME sniffing sfruttano.
- Ambienti di hosting condiviso: nell'hosting condiviso, i file di altri siti sullo stesso server potrebbero essere serviti con header errati. La direttiva
nosniffaggiunge uno strato di difesa indipendentemente dalla qualità della configurazione del server.
L'header di sicurezza più semplice da implementare
Aggiungere X-Content-Type-Options costa una riga. Non ci sono direttive da scegliere, valori da regolare e nessun rischio di rompere funzionalità. A differenza di CSP (che può rompere script inline), HSTS (che può escluderti se il certificato scade) o Referrer-Policy (che può influenzare le analytics), X-Content-Type-Options non ha praticamente svantaggi.
Per Apache (.htaccess o config del virtual host):
Header always set X-Content-Type-Options "nosniff"Per Nginx:
add_header X-Content-Type-Options "nosniff" always;Tramite PHP in WordPress:
add_action('send_headers', function() {
header('X-Content-Type-Options: nosniff');
});WordPress invia già X-Content-Type-Options: nosniff per le pagine admin e le risposte REST API fin dalla versione 4.8. Le pagine front-end della maggior parte delle installazioni WordPress però non contengono questo header, a meno che tu non lo aggiunga a livello di server o tramite un plugin di sicurezza.
Come i browser moderni gestiscono il MIME sniffing
Il comportamento dei browser è migliorato significativamente nel tempo. Le versioni moderne di Chrome, Firefox, Safari ed Edge sono molto meno aggressive con il MIME sniffing rispetto ai browser dell'era di Internet Explorer. Chrome ad esempio blocca già in molte situazioni script con MIME type non-script, anche senza l'header nosniff.
Tuttavia, ci sono ancora casi limite in cui lo sniffing avviene, e i browser più vecchi possono essere ancora vulnerabili. L'header nosniff fornisce un'istruzione chiara e definitiva che elimina ogni ambiguità. È una best practice indipendentemente dai browser usati dai tuoi visitatori.
Interazione con altri header di sicurezza
X-Content-Type-Options funziona bene con altri header di sicurezza e non ci sono conflitti di cui preoccuparsi:
- Combinato con CSP offre difesa in profondità: CSP determina quali fonti sono consentite, mentre
nosniffgarantisce che i file da fonti consentite siano trattati come il tipo specificato. - Con HSTS garantisci connessioni cifrate, e con
nosniffassicuri inoltre l'integrità del contenuto. - A differenza di altri header,
nosniffnon interagisce con o sovrascrive altri header. È puramente additivo.
Cosa controlla InspectWP
InspectWP verifica se il tuo sito WordPress invia l'header X-Content-Type-Options: nosniff. Poiché questo header ha un solo valore valido e nessuna complessità di configurazione, non c'è davvero motivo per cui dovrebbe mancare. Se al tuo sito manca questo header, è uno dei guadagni di sicurezza più veloci che puoi ottenere. Aggiungerlo richiede meno di un minuto e offre una protezione significativa contro attacchi di confusione di MIME type, in particolare su siti che gestiscono upload di file.