Defaults.Exposed › Correzioni › Protezione dal MIME-sniffing (X-Content-Type-Options)

Come correggere Protezione dal MIME-sniffing (X-Content-Type-Options)

Un header di una sola riga che impedisce ai browser di indovinare cosa sia davvero un file. Senza di esso, un file che qualcuno carica sul tuo sito, o un file presente sulle tue pagine, può essere interpretato male dal browser ed eseguito come codice: è proprio così che alcuni attacchi trasformano un caricamento dall'aria innocua in un modo per rubare le sessioni dei tuoi clienti.

In sintesi per la tua attività: L'assenza di questo header è un segnale chiaro e facilmente rilevabile che le basi non sono in atto. Da solo raramente mette fuori uso un sito, ma combinato con un modulo di caricamento file o con contenuti generati dagli utenti apre una via a un aggressore per eseguire codice dannoso nei browser dei tuoi visitatori, dirottando sessioni autenticate, rubando dati di carte o credenziali di accesso e mettendoti dalla parte sbagliata di una vicenda di violazione dati. È una delle correzioni più economiche in fatto di sicurezza: una riga, gratis, circa cinque minuti.

Cosa può costarti

• Ogni pagina in cui clienti o personale possono caricare file (avatar, documenti, allegati di assistenza, foto di annunci) diventa una possibile rampa di lancio per attacchi lato browser.
• Un aggressore può camuffare codice dannoso da immagine o file di testo e far sì che il browser del visitatore lo esegua, rubando la sua sessione autenticata sul tuo sito.
• Questionari di sicurezza, controlli delle assicurazioni informatiche e compratori aziendali cercano questo header; la sua assenza viene letta come «non curano le basi» e può rallentare o far affondare una trattativa.
• Browser più vecchi e alcune integrazioni «annusano» i tipi di contenuto e possono gestire male i file in modi che minano la fiducia o fanno trapelare dati.

Perché è importante. I browser, quando un server è vago su cosa sia un file, cercano di indovinare («sniffing») il tipo di contenuto. Gli aggressori sfruttano questa supposizione: caricano un file che il server etichetta come immagine, ma ne confezionano il contenuto in modo che il browser decida che in realtà è JavaScript, e lo esegua. L'header X-Content-Type-Options: nosniff dice a ogni browser di smettere di indovinare e di fidarsi del tipo dichiarato dal server, chiudendo l'intera categoria di trucchi. È un controllo a punteggio che vale 25 punti ed è classificato come gravità media quando manca.

La versione breve per il titolare

C’è un presupposto silenzioso integrato in ogni browser web: quando scarica un file dal tuo sito, cerca di capire di che tipo di file si tratta. Di solito si fida del tuo server. Ma se il tuo server è vago, il browser indovina, e quell’indovinare si chiama MIME-sniffing.

Il problema è che gli aggressori possono manipolare quella supposizione. Possono confezionare un file che il tuo server crede onestamente sia un’immagine innocua, ma che il browser, lasciato a indovinare, decide essere in realtà un pezzo di codice di programma, e lo esegue, proprio dentro il browser del tuo cliente, sul tuo dominio.

Esiste un’istruzione di una sola riga che spegne l’indovinare: X-Content-Type-Options: nosniff. Dice a ogni browser: «non indovinare, fidati esattamente di ciò che ti dice il mio server». È tutta la correzione. È gratuita, richiede circa cinque minuti e, su un sito ben costruito, non rompe nulla.

Questo controllo cerca quell’header. Se manca, perdi 25 punti ed è classificato come problema di gravità media, non perché l’header da solo sia una catastrofe, ma perché la sua assenza è un segnale affidabile che le basi non sono state messe in sicurezza.

Quanto può costarti

Sono scenari realistici a livello aziendale, non teatro del caso peggiore.

• L’«allegato innocuo» che non lo era. Gestisci un portale di assistenza o un marketplace dove i clienti caricano file: ricevute, foto, documenti. Un aggressore carica un file che il tuo sistema memorizza e serve come immagine. Senza nosniff, il browser della vittima indovina che il file è in realtà uno script e lo esegue, rubando in silenzio la sessione autenticata di quel visitatore sul tuo sito. Ora l’aggressore è lui: piazza ordini, legge i messaggi, cambia i dati. Te ne accorgi quando i clienti iniziano a lamentarsi di attività che non hanno svolto.

• La trattativa che si blocca su un questionario di sicurezza. Il reparto acquisti di un cliente più grande esegue una scansione automatica del tuo sito prima di firmare. Gli header di sicurezza mancanti emergono all’istante. Anche se non c’è mai stato uno sfruttamento, il report dice «header di sicurezza web di base assenti», e all’improvviso ti ritrovi a rispondere a domande di rimedio e a posticipare la data di chiusura di settimane, per una correzione che avrebbe richiesto cinque minuti.

• Il rinnovo dell’assicurazione informatica che si fa più difficile. Sempre più assicuratori eseguono scansioni esterne prima di quotare o rinnovare. Un profilo di header pulito è una prova economica di igiene; uno mancante è un piccolo neo che, sommato ad altri, fa salire il premio o peggiorare le condizioni.

• Il colpo alla reputazione difficile da rimediare. Se un incidente di furto di sessione risale a un file servito dal tuo dominio, la storia non è «mancava un header oscuro», è «[la tua azienda] ha fatto trapelare gli account dei clienti». È questa la versione che i clienti ricordano, e costa molto più della correzione.

Nessuno di questi scenari richiede un aggressore sofisticato. L’abuso del MIME-sniffing è ben compreso e automatizzato, ed è proprio per questo che gli scanner segnalano l’header mancante con tanta fermezza.

Cos’è davvero

Quando un browser riceve un file, il server dovrebbe etichettarlo con un tipo di contenuto (per esempio image/png per un’immagine PNG o text/html per una pagina web). Storicamente i browser non si fidavano del tutto di quell’etichetta, in parte perché alcuni server sbagliavano, quindi davano un’occhiata ai byte reali del file e decidevano da soli. Quell’occhiata è il MIME-sniffing.

Era una comodità diventata un rischio. Se un aggressore riesce a far arrivare un file sul tuo sito (tramite un modulo di caricamento, un campo commenti, un documento importato) e a influenzarne il contenuto, può confezionare qualcosa che il server etichetta in modo innocuo ma che il browser annusa come script eseguibile. Il browser lo esegue allora sul tuo dominio, con tutta la fiducia che il tuo dominio porta con sé.

X-Content-Type-Options: nosniff elimina del tutto l’indovinare. Con questo impostato, al browser viene detto: usa il tipo dichiarato dal server e nient’altro. Un file etichettato come immagine viene trattato come immagine, punto, anche se il suo contenuto sembra script. Il vettore d’attacco si chiude.

Come si presenta una configurazione corretta: ogni risposta del tuo sito, pagine e risorse allo stesso modo, porta esattamente questo header:

X-Content-Type-Options: nosniff

Non esiste altro valore valido né nulla da regolare. Se la tua CDN e il tuo server lo aggiungono entrambi (così vedi nosniff, nosniff), va bene e conta comunque come superato.

Come correggerlo (gratis, circa 5 minuti)

Passa questa sezione a chi gestisce il tuo sito: il tuo referente IT, lo sviluppatore web o l’assistenza dell’hosting. La correzione è gratuita e rapida; non c’è nulla da acquistare. Quello che chiedi è semplice: «Aggiungi l’header di risposta X-Content-Type-Options: nosniff a ogni pagina e risorsa del sito.»

Ecco il dettaglio per loro, per piattaforma comune.

Cloudflare (o una CDN/proxy simile) — spesso il punto più rapido, copre tutto il sito in un colpo solo:

• Usa una Response Header Transform Rule (Rules → Transform Rules → Modify Response Header) per impostare X-Content-Type-Options su nosniff per tutte le richieste in entrata. Si applica a tutto il sito senza toccare il server di origine.

Nginx — aggiungi dentro il blocco server (o location) pertinente:

add_header X-Content-Type-Options "nosniff" always;

La parola chiave always garantisce che venga inviato anche sulle risposte di errore. Ricarica Nginx dopo il salvataggio.

Apache — richiede mod_headers abilitato; nella configurazione del sito o in .htaccess:

Header always set X-Content-Type-Options "nosniff"

IIS / hosting Windows — in web.config sotto <system.webServer>:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

Node / Express — impostalo per ogni risposta:

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

(Oppure usa il pacchetto helmet, che imposta questo e diversi altri header di sicurezza per impostazione predefinita.)

Siti su Google Workspace / Microsoft 365: questi gestiscono la tua email e i tuoi documenti, non l’hosting del tuo sito pubblico, quindi l’header non si imposta lì: si imposta dove viene servito il tuo sito (la tua CDN, il server web o il costruttore di siti). Se usi un costruttore di siti in hosting (Squarespace, Wix, Shopify e simili), molti aggiungono questo header automaticamente; verifica il risultato invece di darlo per scontato, e chiedi alla loro assistenza se manca.

Dopo la pubblicazione, verificalo. Riesegui la tua scansione, oppure fai controllare al tuo sviluppatore gli header di risposta negli strumenti di sviluppo del browser (scheda Network → clic su una richiesta qualsiasi → Response Headers) e conferma che X-Content-Type-Options: nosniff sia presente. Prova brevemente il sito per confermare che nulla di formattato o con script si sia rotto: su un sito ben costruito, nulla si romperà.

Errori comuni

• Impostarlo solo sulla homepage. L’header deve essere su ogni risposta, incluse immagini, script, fogli di stile e file caricati, perché sono queste le risorse che lo sniffing colpisce. Applicalo a livello di server o CDN così è universale, non pagina per pagina.
• Un errore di battitura nel valore. L’unico valore valido è nosniff. Qualsiasi altra cosa (un valore vuoto, un refuso) fallisce il controllo e non offre alcuna protezione. Lo scanner riporta il valore effettivamente visto così puoi individuare un refuso.
• Credere che sostituisca una Content Security Policy. nosniff è un solo strato. Non controlla quali script possono essere eseguiti: quello è compito della CSP. Aggiungi nosniff ora come vittoria rapida, e tratta una CSP vera e propria come il seguito più ampio.
• Rimuovere il «duplicato». Se sia la tua CDN sia l’origine lo impostano, lo vedrai due volte. È innocuo: non perdere tempo a eliminarne uno.
• Pagare per averlo. È una modifica di configurazione gratuita. Monitoraggio, audit e dashboard di portafoglio sono legittimamente a pagamento; aggiungere un singolo header no.

Passa questo al tuo referente IT

Il riassunto tecnico: questo controllo ispeziona gli header di risposta HTTP e supera quando X-Content-Type-Options è presente e il suo valore (senza distinzione tra maiuscole e minuscole) contiene nosniff, incluso il caso multi-origine nosniff, nosniff in cui CDN e origine lo impostano entrambi. Mancante o con qualsiasi valore diverso da nosniff fallisce. È un controllo a punteggio P2 che vale 25 punti, classificato gravità media quando fallisce, e mappa su OWASP Top 10 A05 (Security Misconfiguration). Il rimedio è un singolo header di risposta statico applicato a tutte le risposte; non ci sono parametri né valori alternativi validi. Impostalo al perimetro (CDN) per la copertura di tutto il sito, oppure sul server web con la semantica always così da emetterlo anche sulle risposte di errore, poi conferma negli header di risposta.

FAQ