En-têtes HTTP · notes de sécurité

Microsoft récolte un F, mon blog un A : ce qu'une note de sécurité mesure vraiment

2026-07-20 · HardStacked · 7 min de lecture

Le 20 juillet 2026, on a passé trois domaines dans securityheaders.com, le scanner gratuit qui note les en-têtes de réponse HTTP d'un site, de A+ jusqu'à F. Résultats, dans l'ordre : microsoft.com récolte un F. facebook.com récolte un A. Et ce blog, un site statique sans équipe, sans budget et sans backend, récolte aussi un A.

Le titre facile serait « un petit blog bat Microsoft en sécurité ». Ce titre est faux, et les façons dont il est faux sont plus utiles que les notes elles-mêmes. Chacune de ces trois lettres a une raison derrière elle, et aucune de ces raisons n'est « cette compagnie a oublié ».

1. Le badge mesure un axe, pas votre sécurité

D'abord, ce que le scanner fait réellement. Il envoie une requête et lit les en-têtes de la réponse : Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Six lignes de texte que le serveur attache à chaque page qu'il sert. C'est tout l'examen.

Il ne teste pas si le serveur est à jour. Il ne voit ni l'authentification, ni le pare-feu, ni le réseau interne, ni les humains, ni ce qui se passe une fois connecté. Un site peut servir six en-têtes parfaits devant une application trouée, et un site noté F peut reposer sur une infrastructure que votre banque envierait. La note mesure l'axe des en-têtes, tout l'axe des en-têtes, et rien que l'axe des en-têtes.

Donc non, notre A ne veut pas dire que ce blog est « plus sécuritaire » que Microsoft. Il veut dire quelque chose de plus étroit et de quand même intéressant : sur cet axe mesurable, le géant échoue, et comprendre pourquoi vous montre comment le web est réellement construit.

2. Pourquoi microsoft.com échoue : le F est une décision d'affaires

Microsoft emploie certains des meilleurs ingénieurs en sécurité au monde. Sa page d'accueil ne sert pourtant aucune Content-Security-Policy digne d'être notée. Comment ?

Chargez microsoft.com avec l'onglet réseau ouvert et comptez ce qui arrive : télémétrie, balises publicitaires, frameworks de tests A/B, plusieurs CDN, widgets intégrés. Des dizaines de scripts venus de dizaines de domaines tiers, gérés par des équipes différentes sur des cycles de livraison différents. Une CSP stricte est une liste blanche : chacune de ces sources devrait être énumérée, tenue à jour, et la page casserait le jour où une équipe marketing ajoute une balise dont l'équipe sécurité n'a jamais entendu parler.

Devant ça, les propriétaires d'une page d'accueil marketing font un calcul rationnel : pas de CSP stricte. Le F n'est pas de l'ignorance. C'est le coût visible d'une page bâtie sur des dizaines de tiers, accepté par des gens qui ont décidé que la machinerie de suivi valait plus que l'en-tête. Vous trouverez le même F sur une bonne part du web corporatif, pour la même raison.

3. Pourquoi facebook.com passe : les nonces, le truc qu'un site statique ne peut pas copier

La page d'accueil de Facebook transporte autant de scripts que celle de Microsoft, et elle sert pourtant une CSP stricte qui lui vaut son A. La différence tient à un mécanisme appelé nonce, et il ne fonctionne que si vos pages sont générées par un serveur, à chaque requête.

À chaque chargement de page, le serveur invente un jeton aléatoire frais et en fait deux choses : il l'estampille sur chaque balise script légitime, et il annonce le même jeton dans l'en-tête CSP.

Le navigateur n'exécute que les scripts qui portent le jeton du jour. Un script injecté par un attaquant n'était pas là quand le serveur a estampillé la page : il n'a pas de nonce et meurt en silence. Le problème de la liste blanche disparaît : on n'énumère plus des domaines de confiance, on marque des scripts de confiance, des milliers s'il le faut. Meta a été l'un des premiers déploiements de CSP à grande échelle, et c'est sur cette machinerie que sa note repose.

Le hic : un nonce doit être unique par requête, ce qui exige un backend qui rend chaque page. Un site statique comme celui-ci sert les mêmes octets à tout le monde ; un « nonce statique » serait un mot de passe collé sur la porte. Un site statique passe donc par un autre chemin, on y arrive. Mais d'abord, la ligne la plus intéressante du scan de Facebook.

4. L'en-tête que Facebook ne resserrera pas, et pourquoi

Scannez facebook.com et regardez au-delà de la note, dans le détail : le point faible est Referrer-Policy, l'en-tête qui contrôle quelle portion de l'URL courante fuit vers le prochain site où vous cliquez. Ce blog sert strict-origin-when-cross-origin ; la politique de Facebook est plus lâche. Les ingénieurs qui ont bâti la machinerie à nonces ci-dessus pourraient évidemment livrer une politique de referrer stricte avant le dîner.

Ils ne l'ont pas fait, et la raison probable n'est pas technique. Le referrer, c'est de la donnée d'attribution : il dit au site de destination quelle page, quel lien, quelle campagne a produit le clic. Pour une entreprise de publicité, cette donnée n'est pas un déchet, c'est de l'inventaire. Une politique stricte brûlerait un peu de leur propre produit pour acheter un peu de votre vie privée. On ne voit pas les décisions internes de Meta de l'extérieur ; on observe quel en-tête est resté lâche chez une compagnie qui a toutes les ressources pour le resserrer, et que le lâche est précisément celui dont son modèle d'affaires se nourrit.

C'est la vraie leçon de tout l'exercice : la posture de sécurité d'un site reflète ses incitatifs au moins autant que sa compétence. Le F de Microsoft est le coût d'une machinerie de suivi. Le A de Facebook s'arrête exactement là où le commerce publicitaire commence. Et un site qui n'a aucune donnée à vendre peut se payer la rigueur partout, gratuitement.

5. Comment un site statique gagne un A honnête

Notre A coûte un fichier. Cloudflare Pages, comme la plupart des hébergeurs statiques, lit un fichier _headers à la racine du déploiement et attache ses lignes à chaque réponse. Le nôtre déclare les six en-têtes, et vous pouvez vérifier ce que n'importe quel site sert réellement, y compris celui-ci, depuis n'importe quel terminal :

Si la CSP peut être stricte, c'est que le site est plate, dans le meilleur sens du terme : pas de CDN, pas de polices externes, pas de gestionnaire de balises, les polices incorporées dans un seul fichier CSS, le favicon inclus dans la page. Presque tout se résout en 'self'. Les deux exceptions sont méritées et explicites : le formulaire de contact poste vers son relais, et la balise d'analytique rapporte à la maison. Rien d'autre n'entre.

Une limite honnête : notre CSP permet les scripts 'unsafe-inline', parce que la page transporte deux petits scripts incorporés et qu'aucun backend n'existe pour y estampiller des nonces. Cette seule permission est ce qui sépare notre A d'un A+. La route du A+ pour un site statique, c'est de hacher chaque script incorporé dans l'en-tête, et chaque modification future d'un script casse la page en silence jusqu'à ce que le hash soit recalculé. Pour un site entretenu à la main, on a choisi la note qui survit à son propriétaire : un A durable plutôt qu'un A+ fragile.

Ce que les trois notes disent ensemble

Un scanner, un après-midi, trois lettres : un F qui est en réalité une décision d'affaires, un A bâti sur une machinerie qu'un petit site ne peut pas copier, troué exactement en forme de modèle publicitaire, et un A qui coûte un fichier parce que le site derrière n'a rien à vendre d'autre que sa configuration. Les lettres sont creuses. Les raisons sont toute l'histoire, et les raisons ramènent toujours à la même question : qui profite de ce trou laissé ouvert ?