Defaults.Exposed › Corrections › Protection contre le reniflage MIME (X-Content-Type-Options)

Comment corriger Protection contre le reniflage MIME (X-Content-Type-Options)

Un en-tête d'une ligne qui empêche les navigateurs de deviner ce qu'est réellement un fichier. Sans lui, un fichier déposé sur votre site — ou un fichier présent sur vos propres pages — peut être mal interprété par le navigateur et exécuté comme du code, ce qui est précisément la façon dont certaines attaques transforment un dépôt d'apparence anodine en moyen de voler les sessions de vos clients.

En clair, pour votre entreprise : L'absence de cet en-tête est un signe clair et facilement détectable que les bases ne sont pas en place. À lui seul il met rarement un site à terre, mais combiné à un formulaire d'envoi de fichiers ou à du contenu généré par les utilisateurs, il ouvre une voie à un attaquant pour exécuter du code malveillant dans le navigateur de vos visiteurs — détournant des sessions connectées, volant des identifiants ou des numéros de carte saisis, et vous plaçant du mauvais côté d'une affaire de fuite de données. C'est l'un des correctifs les moins chers en sécurité : une ligne, gratuit, environ cinq minutes.

Ce que cela peut vous coûter

• Toute page où des clients ou des employés peuvent envoyer des fichiers (avatars, documents, pièces jointes de support, photos d'annonces) devient un point de départ possible pour des attaques côté navigateur.
• Un attaquant peut déguiser du code malveillant en image ou en fichier texte et faire en sorte que le navigateur du visiteur l'exécute — volant sa session connectée sur votre site.
• Les questionnaires de sécurité, les contrôles d'assurance cyber et les acheteurs grands comptes recherchent cet en-tête ; son absence se lit comme « ils ne font pas les bases » et peut bloquer ou couler une affaire.
• Les navigateurs plus anciens et certaines intégrations « reniflent » les types de contenu et peuvent mal traiter des fichiers de façons qui brisent la confiance ou laissent fuir des données.

Pourquoi c'est important. Quand un serveur reste vague sur ce qu'est un fichier, les navigateurs tentent de deviner (« renifler ») le type de contenu. Les attaquants exploitent cette devinette : ils déposent un fichier que le serveur étiquette comme une image, mais en fabriquent le contenu de sorte que le navigateur décide qu'il s'agit en réalité de JavaScript — et l'exécute. L'en-tête X-Content-Type-Options: nosniff dit à chaque navigateur de cesser de deviner et de faire confiance au type déclaré par le serveur, fermant toute cette catégorie de piège. C'est un contrôle noté valant 25 points, classé en gravité moyenne lorsqu'il est absent.

La version courte pour le dirigeant

Il y a une hypothèse silencieuse intégrée à chaque navigateur web : quand il télécharge un fichier depuis votre site, il tente de déterminer de quel type de fichier il s’agit. Habituellement il fait confiance à votre serveur. Mais si votre serveur est vague, le navigateur va deviner — et cette devinette s’appelle le reniflage MIME.

Le problème, c’est que les attaquants peuvent piéger cette devinette. Ils peuvent fabriquer un fichier que votre serveur croit honnêtement être une image inoffensive, mais que le navigateur, laissé à sa devinette, décide d’être en réalité un morceau de code de programme — et qu’il exécute alors, directement dans le navigateur de votre client, sur votre domaine.

Il existe une instruction d’une ligne qui désactive cette devinette : X-Content-Type-Options: nosniff. Elle dit à chaque navigateur : « ne devine pas — fais exactement confiance à ce que mon serveur t’indique. » C’est tout le correctif. Il est gratuit, prend environ cinq minutes, et sur un site correctement construit il ne casse rien.

Ce contrôle recherche cet en-tête. S’il est absent, vous perdez 25 points et le problème est classé en gravité moyenne — non pas parce que l’en-tête à lui seul serait une catastrophe, mais parce que son absence est un signe fiable que les bases n’ont pas été verrouillées.

Ce que cela peut vous coûter

Voici des scénarios réalistes, au niveau de l’entreprise — pas du théâtre catastrophiste.

• La « pièce jointe inoffensive » qui ne l’était pas. Vous gérez un portail de support ou une place de marché où les clients envoient des fichiers — reçus, photos, documents. Un attaquant dépose un fichier que votre système stocke et sert comme une image. Sans nosniff, le navigateur d’une victime devine que le fichier est en réalité un script et l’exécute — volant discrètement la session connectée de ce visiteur sur votre site. L’attaquant devient désormais lui : il passe des commandes, lit des messages, modifie des coordonnées. Vous l’apprenez quand des clients commencent à se plaindre d’une activité qu’ils n’ont pas effectuée.

• L’affaire qui cale sur un questionnaire de sécurité. L’équipe achats d’un client plus important lance un scan automatisé de votre site avant de signer. Les en-têtes de sécurité manquants apparaissent instantanément. Même si rien n’a jamais été exploité, le rapport indique « en-têtes de sécurité web de base absents », et vous voilà soudain à répondre à des questions de remédiation et à repousser votre date de signature de plusieurs semaines — pour un correctif qui aurait pris cinq minutes.

• Le renouvellement d’assurance cyber qui se complique. De plus en plus d’assureurs lancent des scans externes avant de coter ou de renouveler. Un profil d’en-têtes propre est une preuve d’hygiène peu coûteuse ; un en-tête manquant est une petite tache qui, cumulée avec d’autres, fait grimper votre prime ou durcit vos conditions.

• L’atteinte à la réputation difficile à effacer. Si un incident de détournement de session remonte à un fichier servi depuis votre domaine, l’histoire n’est pas « un en-tête obscur manquait » — c’est « [votre entreprise] a laissé fuir des comptes clients ». C’est cette version-là dont les clients se souviennent, et elle coûte bien plus cher que le correctif ne l’aurait jamais fait.

Aucun de ces cas ne requiert un attaquant sophistiqué. L’abus du reniflage MIME est bien compris et automatisé, ce qui explique précisément pourquoi les scanners signalent l’en-tête manquant avec autant de fermeté.

Ce que c’est vraiment

Quand un navigateur reçoit un fichier, le serveur est censé l’étiqueter avec un type de contenu (par exemple image/png pour une image PNG ou text/html pour une page web). Historiquement, les navigateurs ne faisaient pas pleinement confiance à cette étiquette — en partie parce que certains serveurs se trompaient — alors ils jetaient un œil aux octets réels du fichier et décidaient eux-mêmes. Ce coup d’œil, c’est le reniflage MIME.

C’était une commodité devenue une vulnérabilité. Si un attaquant parvient à déposer un fichier sur votre site (via un formulaire d’envoi, un champ de commentaires, un document importé) et à en influencer le contenu, il peut fabriquer quelque chose que le serveur étiquette innocemment mais que le navigateur renifle comme un script exécutable. Le navigateur l’exécute alors sur votre domaine, avec toute la confiance qu’il porte.

X-Content-Type-Options: nosniff supprime entièrement la devinette. Une fois défini, le navigateur reçoit l’ordre suivant : utilise le type déclaré par le serveur et rien d’autre. Un fichier étiqueté comme image est traité comme une image, point — même si son contenu ressemble à un script. Le vecteur d’attaque se ferme.

À quoi ressemble une situation « correcte » : chaque réponse de votre site — pages comme ressources — porte exactement cet en-tête :

X-Content-Type-Options: nosniff

Il n’existe aucune autre valeur valide et rien à régler. Si votre CDN et votre serveur l’ajoutent tous deux (de sorte que vous voyez nosniff, nosniff), c’est parfait et reste validé.

Comment corriger (gratuit, ~5 minutes)

Transmettez cette section à la personne qui gère votre site — votre informaticien, votre développeur web, ou le support de votre hébergeur. Le correctif est gratuit et rapide ; il n’y a rien à acheter. Ce que vous demandez est simple : « Ajoutez l’en-tête de réponse X-Content-Type-Options: nosniff à chaque page et ressource du site. »

Voici le détail à leur intention, par plateforme courante.

Cloudflare (ou un CDN/proxy similaire) — souvent l’endroit le plus rapide pour le faire, couvrant tout le site d’un coup :

• Utilisez une Response Header Transform Rule (Rules → Transform Rules → Modify Response Header) pour définir X-Content-Type-Options sur nosniff pour toutes les requêtes entrantes. Cela l’applique à l’ensemble du site sans toucher au serveur d’origine.

Nginx — à ajouter dans le bloc server (ou location) approprié :

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

Le mot-clé always garantit qu’il est envoyé aussi sur les réponses d’erreur. Rechargez Nginx après l’enregistrement.

Apache — nécessite mod_headers activé ; dans la configuration du site ou .htaccess :

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

IIS / hébergement Windows — dans web.config sous <system.webServer> :

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

Node / Express — à définir pour chaque réponse :

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

(Ou utilisez le paquet helmet, qui définit celui-ci et plusieurs autres en-têtes de sécurité par défaut.)

Sites Google Workspace / Microsoft 365 : ces services gèrent votre messagerie et vos documents, pas l’hébergement de votre site public, donc l’en-tête ne s’y règle pas — il se règle là où votre site est réellement servi (votre CDN, serveur web, ou créateur de site). Si vous utilisez un créateur de site hébergé (Squarespace, Wix, Shopify et similaires), beaucoup ajoutent cet en-tête automatiquement ; vérifiez le résultat plutôt que de le supposer, et demandez à leur support s’il manque.

Après le déploiement, vérifiez. Relancez votre scan, ou demandez à votre développeur de vérifier les en-têtes de réponse dans les outils de développement du navigateur (onglet Réseau → cliquez sur une requête → En-têtes de réponse) et de confirmer que X-Content-Type-Options: nosniff est présent. Testez brièvement le site pour confirmer que rien de stylé ou scripté n’a cassé — sur un site correctement construit, rien ne cassera.

Erreurs courantes

• Ne le définir que sur la page d’accueil. L’en-tête doit figurer sur chaque réponse — y compris images, scripts, feuilles de style et fichiers envoyés — car ce sont les ressources que le reniflage affecte. Appliquez-le au niveau du serveur ou du CDN pour qu’il soit universel, et non page par page.
• Une faute de frappe dans la valeur. La seule valeur valide est nosniff. Tout le reste (valeur vide, faute d’orthographe) échoue au contrôle et n’offre aucune protection. Le scanner signalera la valeur réellement constatée pour que vous repériez une coquille.
• Croire qu’il remplace une Content Security Policy. nosniff n’est qu’une couche. Il ne contrôle pas quels scripts ont le droit de s’exécuter — c’est le rôle de la CSP. Ajoutez nosniff maintenant comme gain rapide, et traitez une vraie CSP comme le chantier plus large qui suit.
• Retirer le « doublon ». Si votre CDN et votre origine le définissent tous deux, vous le verrez deux fois. C’est inoffensif — ne perdez pas de temps à en retirer un.
• Le payer. C’est un changement de configuration gratuit. La surveillance, les audits et les tableaux de bord de portefeuille sont légitimement payants ; ajouter un seul en-tête ne l’est pas.

À transmettre à votre informaticien

Le résumé technique : ce contrôle inspecte les en-têtes de réponse HTTP et passe lorsque X-Content-Type-Options est présent et que sa valeur (insensible à la casse) contient nosniff — y compris le cas multi-source nosniff, nosniff où un CDN et l’origine le définissent tous deux. Une valeur absente ou différente de nosniff échoue. C’est un contrôle noté P2 valant 25 points, classé en gravité moyenne en cas d’échec, et correspondant à OWASP Top 10 A05 (Mauvaise configuration de sécurité). La remédiation est un en-tête de réponse statique unique appliqué à toutes les réponses ; il n’y a aucun paramètre et aucune valeur alternative valide. Définissez-le en périphérie (CDN) pour une couverture de tout le site, ou au serveur web avec la sémantique always pour qu’il soit émis aussi sur les réponses d’erreur, puis confirmez dans les en-têtes de réponse.

FAQ