En-têtes de sécurité HTTP : ce qui compte
Les en-têtes de sécurité HTTP sont des consignes que votre serveur envoie au navigateur avec chaque page. Le visiteur ne les voit pas, mais le navigateur les applique : n'utiliser que HTTPS, refuser un script venu d'ailleurs, ne pas laisser un autre site afficher la page. Deux passent avant les autres : HSTS et la politique de sécurité du contenu (CSP).
Ils font partie de ce que l'audit de sécurité relève, à côté du certificat et des cookies.
Un en-tête absent, c'est une protection qui ne s'active pas
Un en-tête de sécurité ne corrige rien dans votre site. Il demande au navigateur de fermer une porte que le site laisse ouverte par défaut. Son absence n'est donc pas une erreur visible : le site fonctionne, et la protection ne se déclenche jamais.
L'agence nationale de la sécurité des systèmes d'information (ANSSI) les range dans ses recommandations pour la mise en œuvre d'un site web : ce sont des défenses en profondeur, qui limitent les conséquences d'une erreur ailleurs dans le site.
Les six en-têtes que l'audit relève, et ce que chacun empêche
Chacun répond à une situation précise. Leur ordre ici suit ce que leur absence laisse faire.
- Strict-Transport-Security (HSTS) demande au navigateur de ne contacter votre site qu'en HTTPS, pendant une durée que vous fixez. Sans lui, un visiteur qui tape votre adresse sans « https » envoie sa première requête en clair, avant d'être redirigé. Il est décrit par la RFC 6797.
- Content-Security-Policy (CSP) liste les sources depuis lesquelles la page peut charger des scripts, des styles ou des images. Un script injecté depuis une source absente de la liste ne s'exécute pas. Le W3C en publie la spécification.
- X-Frame-Options dit si d'autres sites peuvent afficher vos pages dans un cadre. Sans lui, un site tiers peut afficher votre page sous une couche invisible et faire cliquer le visiteur à son insu.
- X-Content-Type-Options demande au navigateur de s'en tenir au type annoncé d'un fichier. Sans lui, le navigateur peut deviner le type, et traiter comme un script un fichier présenté comme du texte.
- Referrer-Policy décide quelle part de l'adresse de la page part vers les sites qu'elle appelle ou vers lesquels elle renvoie. Sans lui, c'est le réglage par défaut du navigateur qui décide, et il varie selon les navigateurs.
- Permissions-Policy déclare les fonctions du navigateur que la page et les contenus qu'elle intègre ont le droit de demander : caméra, micro, géolocalisation.
Le rapport regarde aussi Cross-Origin-Opener-Policy, qui sépare la page des fenêtres d'autres sites qu'elle ouvre, et si votre serveur annonce son logiciel et son numéro de version.
Ce que nous relevons sur les sites audités
40 %n'envoient pas l'en-tête HSTS, qui impose HTTPS dès la première requête
55 %n'ont aucune politique de sécurité du contenu (CSP)
Ces pourcentages portent sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026. Chacun ne compte que les sites où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : ces chiffres décrivent nos audits, pas l'ensemble des sites.
Ce que l'audit regarde, et comment l'absence compte
L'audit lit les en-têtes tels qu'un navigateur les reçoit, sur les pages qu'il visite. Le rapport présente chaque en-tête dans un tableau : présent ou absent, et sa valeur quand il est là.
La valeur compte autant que la présence. Pour HSTS, le rapport relève la durée demandée et si elle couvre les sous-domaines. Pour la CSP, il distingue une politique stricte d'une politique qui autorise tout script écrit dans la page, et qui protège donc peu.
Chaque absence retire un nombre fixe de points à la note du pilier, le même pour tous les sites. Deux audits du même site, sur les mêmes réponses, donnent la même note.
Ce qui se pose en une fois, ce qui demande un projet
La plupart de ces en-têtes se règlent une fois pour tout le site : dans la configuration du serveur, chez l'hébergeur ou le service placé devant lui (CDN), ou par une extension du CMS. X-Content-Type-Options, X-Frame-Options, Referrer-Policy et Permissions-Policy en font partie : ils changent rarement le fonctionnement des pages.
HSTS se pose aussi simplement, mais il engage. Une fois prévenu, le navigateur refuse de contacter votre site en clair pendant toute la durée demandée. L'ANSSI le rappelle : un accès HTTPS durable, sur tous les sous-domaines concernés, en est la condition.
La CSP est un projet. Elle demande d'inventorier tout ce que vos pages chargent : vos scripts, mais aussi la mesure d'audience, le chat, les vidéos, le paiement. Une politique trop large ne protège pas, une politique trop stricte casse des pages. Elle se construit, se teste, puis s'applique. Les cookies ont leurs propres protections, que présente le guide sur les attributs Secure, HttpOnly et SameSite.
Ce que cette vérification ne dit pas
Nous lisons les en-têtes que votre serveur envoie sur les pages visitées. Un espace connecté ou une page d'administration peut en envoyer d'autres, que nous ne voyons pas.
Un en-tête présent ne dit rien de la qualité du code. Il limite les conséquences d'une erreur, il ne la corrige pas.
À lire ensuite
HSTS : ce qu'il protège, ce qu'il engage
HSTS impose HTTPS au navigateur dès la première requête. Ce que règlent max-age, includeSubDomains et preload, ce qui casse, et ce que l'audit lit.
Lire le guide →Cookies HttpOnly, Secure et SameSite
Secure, HttpOnly, SameSite : ce que chaque attribut empêche, quels cookies en ont vraiment besoin, et ce que l'audit relève sur votre site.
Lire le guide →