X-Content-Type-Options est un en-tête HTTP qui empêche les navigateurs d'analyser le type MIME d'une réponse autre que le type de contenu déclaré. Cela permet d'éviter les attaques dans lesquelles les navigateurs pourraient interpréter les fichiers comme ayant un type de contenu différent de celui prévu. L'en-tête doit être défini sur « nosniff » pour appliquer une vérification stricte du type MIME.
X-Content-Type-Options est un en-tête de réponse doté d'une seule valeur significative, nosniff. Normalement, si le Content-Type déclaré par un serveur paraît incorrect ou est absent, le navigateur peut renifler les octets et deviner le type réel, une fonctionnalité de commodité qui peut se révéler dangereuse. Avec nosniff, le navigateur cesse de deviner et respecte exactement le Content-Type déclaré. Il refuse d'exécuter une réponse comme script ou feuille de style à moins que le type ne corresponde (par exemple text/javascript ou text/css), et il renforce les protections Cross-Origin-Read-Blocking. En pratique, cela signifie qu'un fichier étiqueté text/plain par le serveur ne peut être contraint à s'exécuter comme du JavaScript simplement parce que son contenu s'avère être du code valide.
Le MIME sniffing rendait possible une véritable catégorie d'attaques. Un attaquant capable de téléverser ou d'influencer un fichier, disons un avatar d'utilisateur ou un document texte, pouvait forger des octets qu'un navigateur reniflant interprétait comme du HTML ou du JavaScript, transformant un point de téléversement inoffensif en vecteur de XSS stocké. Le sniffing sapait aussi les contrôles d'accès fondés sur le type de contenu. Définir nosniff comble cette faille en forçant le navigateur à se fier au type déclaré par le serveur, si bien qu'un contenu mal étiqueté ou contrôlé par l'attaquant est rendu de façon inerte au lieu d'être exécuté. C'est un petit en-tête universellement pris en charge, sans inconvénient réel sur un site correctement configuré, raison pour laquelle les référentiels de sécurité et les scanners signalent son absence.
Envoyez X-Content-Type-Options: nosniff sur chaque réponse, et assurez-vous que votre application définit effectivement des en-têtes Content-Type corrects, car nosniff rejettera les ressources mal étiquetées. Servez les fichiers téléversés par les utilisateurs depuis une origine distincte ou avec Content-Disposition: attachment le cas échéant, et ne comptez jamais sur le sniffing pour corriger des types erronés. Associez-le à une Content-Security-Policy robuste et à des déclarations de charset correctes pour une couverture complète. Il s'agit d'une question de configuration serveur et CDN plutôt que d'un problème de script tiers, elle se situe donc en dehors du champ d'analyse de charge utile de cside ; traitez-le comme un durcissement standard aux côtés des autres en-têtes de sécurité que votre framework ou votre edge peut émettre par défaut.
La seule valeur valide et significative est nosniff. Malgré le nom au pluriel de l'en-tête, il n'existe pas de liste d'options ; soit vous envoyez X-Content-Type-Options: nosniff pour désactiver le MIME sniffing, soit vous omettez complètement l'en-tête. Toute autre valeur est ignorée par les navigateurs, si bien que le contrôle est de fait activé ou désactivé.
C'est possible, mais uniquement si le serveur envoie des en-têtes Content-Type incorrects. Avec nosniff, une feuille de style mal étiquetée text/plain ou un script servi avec le mauvais type sera rejeté au lieu d'être deviné pour fonctionner. La bonne correction consiste à définir des valeurs Content-Type exactes, non à retirer l'en-tête.
We answer client-side security questions every day. Bring yours.