X-Content-Type-Options

Les navigateurs inspectaient autrefois les premiers octets d'une réponse pour deviner son vrai type dès que le Content-Type déclaré manquait ou semblait faux, un comportement appelé MIME sniffing. X-Content-Type-Options: nosniff met fin à cette devinette : le navigateur fait confiance au type que votre serveur déclare et traite la réponse comme ce type uniquement.

Deviner, c'était justement la surface d'attaque : un fichier uploadé comme image inoffensive mais qui contient en réalité du HTML et du JavaScript pouvait être interprété comme une page et exécuté dans l'origine de votre site, soit un XSS stocké. Ce header ferme ce chemin.

Le header se résume à ça. Il ne fait son travail que si le Content-Type de chaque réponse est correct :

X-Content-Type-Options: nosniff

Valeurs et ce que fait chacune

nosniff, défini dans le standard Fetch, a deux effets.

D'abord, un blocage strict pour les scripts et les feuilles de style. Tout chargement de type script (un <script>, un worker, un shared worker, un service worker, un worklet audio ou paint) doit être servi avec un type MIME JavaScript, et une feuille de style avec exactement text/css. Si le type ne correspond pas, le navigateur bloque la réponse au niveau réseau et elle ne s'exécute jamais ; Chromium journalise une erreur console indiquant que le script a été refusé parce que « strict MIME type checking is enabled ». Sans le header, Chromium exécute encore les scripts servis en text/plain, text/html ou application/octet-stream (les types image, audio, vidéo et CSV sont bloqués comme scripts dans les deux cas).

Ensuite, le navigateur cesse d'inspecter les octets partout ailleurs. Quand une réponse porte un Content-Type, le type déclaré est définitif. Quand elle n'en porte aucun, le navigateur peut encore classer le corps comme texte ou binaire, mais il ne le requalifiera jamais en HTML, en XML ou en PDF.

Chrome embarque aussi Opaque Response Blocking (ORB), qui bloque pour tous les sites les lectures no-cors cross-origin des réponses qui ressemblent à du HTML, du JSON ou du XML, quels que soient les headers envoyés. nosniff rend ce blocage déterministe : un type de la blocklist, un text/plain ou un type absent est bloqué d'office au lieu de dépendre d'un sniffing de confirmation. ORB ne fait rien pour les chargements same-origin, donc le header reste le seul à imposer un typage MIME correct pour vos propres scripts et feuilles de style.

Le volet Content-Type

Le header fait respecter l'étiquette, donc l'étiquette doit être juste sur chaque ressource : les scripts servis avec un type MIME JavaScript (text/javascript), les feuilles de style en text/css, le HTML en text/html. Sur les réponses HTML, déclarez aussi l'encodage des caractères :

Content-Type: text/html; charset=UTF-8

La cheat sheet OWASP sur les headers HTTP le dit sans détour : « the charset attribute is necessary to prevent XSS in HTML pages » (l'attribut charset est nécessaire pour empêcher le XSS dans les pages HTML). La version classique de cette attaque, faire passer du script via UTF-7, est morte parce que les navigateurs ont abandonné cet encodage, mais omettre le charset reste exploitable. Une recherche publiée par Sonar en 2024 a montré que lorsqu'une page omet son charset, Chrome et Firefox auto-détectent ISO-2022-JP, et qu'un attaquant qui contrôle une partie de la page peut utiliser les séquences d'échappement de cet encodage pour sortir de l'échappement en plein document. Soit un XSS qui marchait encore en 2024. Déclarez le charset sur chaque réponse HTML.

Contre quoi cela protège

• Des uploads mal étiquetés exécutés comme HTML ou script. Un avatar.png qui est en réalité un fichier HTML, servi avec un type absent ou inconnu, pouvait être interprété comme une page et s'exécuter dans votre origine, soit un XSS stocké. Avec nosniff, le navigateur s'en tient au type déclaré.
• Une infrastructure mal configurée ou qui retire le type. Un serveur qui omet Content-Type, ou un proxy qui le retire, laisse le navigateur deviner. Le header supprime la devinette, donc une erreur de configuration reste une ressource cassée au lieu de devenir du contenu exécutable.
• Des scripts de worker mal étiquetés. Le blocage strict couvre les workers, shared workers, service workers et worklets, donc une ressource chargée comme worker doit elle aussi porter un type MIME JavaScript.
• Les fuites de données cross-origin. Il renforce le blocage des lectures cross-origin du navigateur (ORB) contre les attaques de classe Spectre en rendant le blocage déterministe plutôt que fondé sur le sniffing.

Le header fait respecter l'étiquette, rien de plus. Une réponse correctement étiquetée text/html s'affiche toujours, du JavaScript correctement étiqueté s'exécute toujours, donc il ne remplace ni la politique de sécurité du contenu (CSP) ni la gestion des uploads (validation, une origine séparée pour le contenu utilisateur).

Risques sans le header

Sans le header, chaque réponse a besoin d'un Content-Type parfait, parce que toute réponse qui n'en a pas peut être réinterprétée. Une seule route de contenu utilisateur qui sert des fichiers avec un type absent ou inconnu, un seul proxy qui retire le header, et un moteur de sniffing peut faire passer pour du HTML un fichier d'apparence inoffensive, dans votre origine. Les moteurs modernes ont réduit le sniffing (ils ne sniffent vers HTML que lorsque le type est absent ou inconnu), donc l'exposition pratique se concentre sur les surfaces mal configurées et les moteurs anciens, ce qui est exactement le rôle de la défense en profondeur.

Risques et pièges à l'usage

• Les scripts mal typés cessent de se charger. Un script légitime servi en text/plain ou application/octet-stream (un serveur de fichiers brut, un objet Amazon S3 uploadé sans type) est bloqué dès que nosniff est déployé. Corrigez les mappings MIME avant d'ajouter le header, pas après.
• Les feuilles de style doivent être exactement text/css. Tout le reste est bloqué, de la même façon que les scripts exigent un type MIME JavaScript.
• Header uniquement. Il n'existe pas d'équivalent <meta> ; il doit être envoyé comme header de réponse.
• Aucun rapport de violation. Les chargements bloqués n'apparaissent que comme erreurs console. Contrairement à CSP, le header n'a aucune intégration avec la Reporting API, donc rien ne vous signale qu'une ressource est cassée en production ; testez avant et après le déploiement.

Comment le mettre en place

1. Auditez vos mappings Content-Type : chaque script servi avec un type MIME JavaScript, chaque feuille de style en text/css, chaque réponse HTML en text/html; charset=UTF-8. Prêtez attention aux serveurs de fichiers et au stockage objet, où le type est celui défini à l'upload.
2. Ajoutez X-Content-Type-Options: nosniff à chaque réponse, réponses d'API comprises. Le définir une fois au niveau du serveur ou du CDN est plus simple que route par route, et il n'y a aucune valeur à régler.
3. Vérifiez le header déployé, et le reste de vos headers de réponse, avec le scanner de headers de sécurité, et surveillez la console du navigateur après le déploiement, à la recherche de scripts ou de feuilles de style refusés.

Recommandation

Envoyez X-Content-Type-Options: nosniff sur chaque réponse :

X-Content-Type-Options: nosniff

La cheat sheet OWASP sur les headers HTTP recommande de l'envoyer sur toutes les réponses que les navigateurs peuvent consommer, et la cheat sheet OWASP sur la sécurité REST étend cela aux réponses d'API. Associez-le à un Content-Type correct sur chaque ressource et à un charset sur le HTML (text/html; charset=UTF-8) : le header fait respecter l'étiquette, donc l'étiquette doit être juste.

Prise en charge par les navigateurs

Pris en charge par tous les moteurs modernes. Microsoft a introduit le header dans Internet Explorer en 2008 ; leur démo était un fichier HTML servi en text/plain qui s'affichait comme du HTML dans les anciennes versions d'Internet Explorer mais comme du texte brut dans la version qui a apporté nosniff. Chrome, Firefox et Safari l'appliquent tous intégralement dans leurs versions actuelles (certaines premières versions de Chrome n'appliquaient pas la vérification des feuilles de style). Firefox applique aussi nosniff aux chargements de page de premier niveau (voir l'annonce de Mozilla) : une navigation dont le type déclaré ne correspond pas affiche une page d'erreur, et un type absent s'affiche en texte brut ou se télécharge.

FAQ

Faut-il nosniff sur les réponses d'API ?

Oui. La cheat sheet OWASP sur la sécurité REST recommande X-Content-Type-Options: nosniff sur chaque réponse, réponses d'API comprises. Il ne coûte rien à envoyer sur tout le site, il empêche qu'une réponse JSON soit prise pour du HTML, et il n'y a aucune valeur à régler, donc définissez-le une fois au niveau du serveur ou du CDN plutôt que route par route.

nosniff casse-t-il quelque chose ?

Seulement les ressources envoyées avec le mauvais Content-Type. Un script servi en text/plain, ou une feuille de style qui n'est pas exactement text/css, est bloqué dès que le header est déployé. Corrigez d'abord vos mappings MIME, puis ajoutez nosniff, de sorte que le contenu correctement étiqueté continue de se charger et que seules les ressources jusque-là mal étiquetées apparaissent en erreur.

nosniff arrête-t-il le XSS ?

Non. Il ferme un chemin précis : un upload mal étiqueté sniffé et exécuté comme HTML ou script dans votre origine. Du HTML correctement étiqueté s'affiche toujours et du JavaScript correctement étiqueté s'exécute toujours, donc vous avez encore besoin d'une politique de sécurité du contenu (CSP) et d'une bonne gestion des uploads. Traitez nosniff comme de la défense en profondeur, pas comme un correctif XSS.

Voir aussi

• Vue d'ensemble des headers de sécurité
• Qu'est-ce que la Content Security Policy, qui restreint ce que peut faire un contenu correctement étiqueté ; nosniff ne fait que faire respecter les étiquettes
• Strict-Transport-Security, le pendant côté transport dans cette section
• Scanner de headers de sécurité pour vérifier vos headers déployés

Sources

• Standard Fetch, header X-Content-Type-Options
• Standard MIME Sniffing
• MDN, X-Content-Type-Options
• OWASP, cheat sheet des headers HTTP
• Sonar, encoding differentials, pourquoi le charset compte
• Microsoft, IE8 security part VI, l'annonce de nosniff