Notre méthode pour durcir les en-têtes de sécurité HTTP

Un site peut être bien écrit, rapide et à jour, et rester exposé par ce qu’il ne dit pas. Les en-têtes de sécurité HTTP sont ces quelques lignes que le serveur ajoute à chaque réponse pour indiquer au navigateur ce qu’il a le droit de faire de la page : quels scripts exécuter, qui peut l’encadrer, quelles informations transmettre en partant. Invisibles pour le visiteur, ils ferment les portes d’entrée les plus banales — et leur absence ne se voit nulle part, sauf le jour où elle sert.

Mesurer avant de toucher quoi que ce soit#

Nous commençons toujours par relever la note du site sur MDN HTTP Observatory, l’outil de référence sur le sujet : une note de A+ à F, un score, et surtout le détail des dix contrôles avec le coût exact de chaque manque. Cette photographie initiale évite de travailler à l’intuition et de dépenser une journée sur un réglage qui ne rapporte rien.

Ce que la mesure révèle est souvent la même chose. Sur dix sites que nous avions livrés puis remis à niveau récemment, tous étaient notés C : deux réglages manquaient, la politique de contenu et l’anti-encadrement, et ces deux-là seuls coûtaient 45 points. Aucun n’était le signe d’un site mal construit — juste d’un sujet que personne n’avait ouvert. Les dix sont aujourd’hui en A+, avec le rapport public consultable pour chacun.

Une politique de contenu, c’est une liste de ce qui est autorisé#

La Content Security Policy est la pièce maîtresse, et la seule qui demande un vrai travail. Elle énumère ce que la page a le droit de charger : d’où viennent les images, les polices, les scripts, quels domaines peuvent être contactés, qui peut l’afficher dans un cadre. Tout ce qui n’y figure pas est refusé par le navigateur.

Nous l’écrivons en refus par défaut : on part de « rien n’est autorisé », puis on ouvre explicitement, type de ressource par type de ressource, ce que le site utilise réellement. L’approche inverse — autoriser largement puis restreindre — laisse toujours passer ce qu’on n’avait pas anticipé, et c’est justement l’imprévu qu’on cherche à bloquer. La contrepartie est claire, et c’est une discipline saine : ajouter demain une police, une vidéo ou un outil de mesure sans l’inscrire dans la politique, c’est le voir bloqué.

D’où l’étape qui prend le plus de temps, et qu’on ne peut pas sauter : l’inventaire du site construit. Pas du code source, du HTML réellement produit — chaque balise qui charge quelque chose, chaque appel réseau. Une politique écrite sans cet inventaire est une panne programmée.

Le piège des scripts écrits dans la page#

Un script chargé depuis un fichier s’autorise par son adresse. Un script écrit directement dans le HTML, lui, n’a pas d’adresse : il s’autorise par empreinte cryptographique, recalculée à chaque build puisque la moindre espace la change.

C’est là que se cache le vrai danger de l’exercice, et il n’est pas théorique : un script dont l’empreinte manque est refusé silencieusement par le navigateur, alors que le build, lui, reste vert. La panne n’apparaît qu’en production, et seulement chez le visiteur. Nous posons donc systématiquement un contrôle automatique dans la chaîne d’intégration continue : il recalcule, page par page, l’empreinte de chaque script et de chaque style écrits dans le HTML, vérifie qu’elle figure bien dans la politique de cette page, et casse la publication au premier écart. Sans ce garde-fou, une politique stricte est une promesse tenue par personne.

Ce que la page ne peut pas porter elle-même#

Quatre réglages ne valent qu’en en-tête de réponse HTTP, c’est-à-dire côté hébergement, CDN ou reverse proxy :

• L’anti-encadrement (frame-ancestors), qui empêche un tiers d’afficher votre site dans un cadre invisible pour détourner les clics de vos visiteurs. La spécification du W3C précise que cette directive est ignorée quand la politique est délivrée par une balise meta : écrite dans la page, elle ne protège de rien.
• HSTS (RFC 6797), qui impose au navigateur de ne plus jamais se connecter au site autrement qu’en HTTPS, même si un lien lui demande le contraire.
• Referrer-Policy, qui décide de ce que vos visiteurs révèlent de leur provenance aux sites vers lesquels ils partent.
• Permissions-Policy, qui refuse par avance l’accès à la caméra, au micro ou à la position — des capacités qu’un site vitrine n’utilise jamais et qu’il n’a donc aucune raison de laisser ouvertes.

Ce que ces réglages ne font pas#

Autant le dire, parce que la note est flatteuse et qu’elle peut tromper : un A+ ne dit rien de la solidité de votre serveur, de la fraîcheur de vos dépendances, de la qualité de vos mots de passe ni de l’existence d’une sauvegarde restaurable. Il mesure une chose précise et utile : ce que le navigateur d’un visiteur a le droit de faire de votre page. C’est une couche parmi d’autres, la moins coûteuse à poser, et celle qu’on trouve le plus souvent vide — mais elle ne remplace ni les contrôles de sécurité menés tout au long du développement, ni l’hygiène numérique quotidienne de vos équipes.

L’inverse est vrai aussi : la note ne récompense pas tout ce qui compte. Un site peut viser A+ et rester bavard dans ses messages d’erreur, ou exposer une interface d’administration sans second facteur. Nous la lisons donc pour ce qu’elle est : un indicateur objectif, public, opposable à un questionnaire client ou à un assureur — pas un certificat de sécurité.

Remesurer, puis continuer à mesurer#

La mesure finale ne se fait pas sur le site construit en local mais sur le site réellement servi : un CDN peut réécrire le HTML au passage et y injecter un script que le contrôle de build n’a jamais vu. C’est une vérification de quelques secondes qui a déjà évité des surprises.

Et une note obtenue n’est pas une note acquise. Un contenu ajouté, un outil de mesure branché, un CDN qui change un réglage : chacun peut défaire le travail sans que personne le remarque. C’est la raison pour laquelle ces contrôles font partie de notre gestion de site au quotidien et de notre audit technique — au même titre que la performance ou l’accessibilité, et dans le prolongement direct de notre méthode de vérification de la sécurité.

Cette méthode a été appliquée sur nos propres pages comme sur celles de nos clients — Ty Loulic, Cap-Horn, notre site — toutes notées A+ aujourd’hui. Ce n’est pas un exploit technique : c’est une case qu’il suffit de ne pas laisser vide.