Les en-têtes de sécurité que votre site oublie (presque) toujours

Le principe

À chaque réponse, un serveur web peut ajouter des instructions invisibles à destination du navigateur : « n’exécute jamais ce site dans une iframe », « ne charge que mes propres scripts », « force toujours le HTTPS ». Ces instructions s’appellent des en-têtes de sécurité.

Elles ne coûtent rien techniquement à activer, mais la majorité des sites ne les ont tout simplement jamais configurées. Sans elles, le navigateur reste en configuration « par défaut » — la moins protectrice possible, faute d’instruction contraire.

Les en-têtes qui comptent le plus

Content-Security-Policy limite précisément d’où peuvent venir les scripts et styles chargés par la page, et bloque une grande partie des attaques XSS même si une faille existe ailleurs dans le code. X-Frame-Options (et son successeur frame-ancestors en CSP) empêche votre site d’être piégé dans une iframe invisible — la base du clickjacking.

Strict-Transport-Security force le navigateur à toujours utiliser le HTTPS pour votre domaine, même si un lien pointe par erreur vers du HTTP. X-Content-Type-Options: nosniff empêche le navigateur de deviner tout seul le type d’un fichier et de l’exécuter comme un script par erreur d’interprétation.

Ce que leur absence coûte réellement

Sans CSP, une seule faille XSS oubliée quelque part dans le code devient immédiatement exploitable à son plein potentiel, sans aucun filet de sécurité supplémentaire. Sans X-Frame-Options, votre page de paiement peut être invisiblement superposée sous un faux jeu ou une fausse publicité — le visiteur croit cliquer sur le jeu, il valide en réalité un virement (clickjacking).

Sans HSTS, un attaquant en position réseau (un faux point d’accès wifi public, par exemple) peut forcer une connexion non chiffrée et lire les échanges en clair, y compris des identifiants.

Comment s’en protéger

La plupart de ces en-têtes s’ajoutent en quelques lignes seulement : au niveau du serveur web (Nginx, Apache) ou via un middleware applicatif dédié (Helmet.js pour Node.js, django-security pour Django, une poignée de lignes dans Symfony ou Laravel).

Commencez par une CSP en mode « report-only » pour observer son effet sans rien casser sur le site en production, puis resserrez-la progressivement une fois les emplacements légitimes identifiés. Vérifiez le résultat final avec un outil public dédié (par exemple securityheaders.com).

Comment SauronSec la détecte

Analyse passive, en lecture seule, de chaque réponse HTTP : chaque en-tête attendu est vérifié présent, avec une valeur réellement protectrice — un X-Frame-Options mal configuré ne compte pas comme une protection valide.

Anti-faux-positif assumé : l’attribut Secure d’un cookie n’est exigé que sur un site en HTTPS (il serait inutile ailleurs), et HttpOnly n’est jamais réclamé sur un cookie XSRF-TOKEN conçu par nature pour être lu en JavaScript — le signaler serait une fausse alerte, pas une vraie faille à corriger.