Vérificateur d'en-têtes de sécurité HTTP
Ce que fait chaque en-tête, ce que dit réellement le vôtre et la ligne à ajouter. Aucune note lettre.
Par où commencer, si vous commencez
Les en-têtes n’ont pas tous la même valeur, ni le même risque au déploiement. Dans l’ordre qui offre le plus de protection pour le moins de risque de casse :
| En-tête | Empêche | Risque de casser quelque chose |
|---|---|---|
Strict-Transport-Security | La rétrogradation HTTPS à la première visite | Aucun, si vous êtes déjà en HTTPS exclusif |
X-Content-Type-Options | Le reniflage de type MIME sur les fichiers envoyés | Aucun en pratique |
Referrer-Policy | La fuite d’URL vers des tiers | Faible — peut affecter l’attribution dans vos statistiques |
X-Frame-Options / frame-ancestors | Le détournement de clic | Faible, sauf si quelque chose vous intègre légitimement |
Permissions-Policy | Qu’un cadre intégré réclame la caméra ou la localisation | Faible |
Content-Security-Policy | L’exécution de script injecté | Élevé. Commencez en mode rapport seul. |
La dernière ligne est celle qui compte le plus et celle qui demande un vrai travail. Tout ce qui se trouve au-dessus, c’est une après-midi.
HSTS, et la seule décision irréversible qu’il contient
Strict-Transport-Security indique au navigateur d’utiliser HTTPS pour cet hôte pendant les max-age prochaines secondes, quoi qu’il arrive. Cela referme une brèche étroite mais réelle : la personne qui tape example.com émet une requête en clair avant votre redirection, et cette requête peut être interceptée.
Strict-Transport-Security: max-age=31536000; includeSubDomainsincludeSubDomains compte plus qu’il n’y paraît. Sans lui, un sous-domaine servi en HTTP peut encore poser des cookies pour le domaine parent. Avec lui, chaque sous-domaine doit être en HTTPS exclusif sous peine de devenir injoignable — vérifiez donc avant de l’ajouter.
La directive preload est celle à peser longuement. Elle inscrit votre domaine dans les listes de préchargement livrées avec les navigateurs : HTTPS est imposé avant même la première requête. Elle est aussi, dans les faits, irréversible : le retrait suppose une demande auprès des mainteneurs de la liste, puis l’attente des versions successives des navigateurs — soit des mois. Excellente quand vous êtes sûr ; mauvaise idée à ajouter à la légère.
CSP : le mode rapport seul n’est pas facultatif
Une Content-Security-Policy est le seul en-tête de cette liste qui empêche un script injecté de s’exécuter, et le seul qui puisse mettre votre site à terre. Les deux faits découlent de la même propriété : elle restreint ce qui a le droit de se charger.
Déployez-la en mode rapport seul, avec un collecteur, et laissez-la quelques semaines sous trafic réel. Ce que vous y trouverez n’est pas ce que la lecture du code laissait prévoir : il y aura un hébergeur de polices oublié, une iframe de paiement, et souvent un script injecté en bordure de CDN qui ne figure dans aucun fichier source. Cette dernière catégorie, c’est précisément ce que le mode rapport seul est là pour révéler.
Content-Security-Policy-Report-Only: default-src 'self';
script-src 'self'; object-src 'none'; base-uri 'self';
report-uri /csp-reportDeux choses annulent l’essentiel du bénéfice. 'unsafe-inline' dans script-src autorise exactement le script en ligne injecté que la politique doit empêcher — les nonces ou les empreintes sont la porte de sortie. Et 'unsafe-eval' réactive eval et sa parenté, dont certaines anciennes versions de frameworks ont encore besoin. Le vérificateur signale les deux comme un affaiblissement plutôt que comme une absence, car une politique qui les contient fait encore un travail utile ; elle ne fait simplement pas l’essentiel.
Des en-têtes dont le conseil a expiré
- `X-XSS-Protection` — pilotait un filtre de navigateur retiré de tous les grands navigateurs, et qui, en son temps, pouvait lui-même être manipulé pour casser des pages. Ce n’est pas un en-tête à poser en 2026.
- `Expect-CT` — obsolète. La Certificate Transparency est désormais imposée sans condition : l’en-tête ne fait plus rien.
- `Feature-Policy` — renommé en
Permissions-Policy, avec une autre syntaxe. Seul le nouveau nom est pris en compte. - `Public-Key-Pins` — retiré des navigateurs, et à juste titre. Une erreur dedans rendait votre domaine inutilisable pendant toute la durée de vie de l’empreinte, sans moyen de revenir en arrière.
Ce que ceci ne vérifie pas
Une page, une réponse. L’outil lit les en-têtes de la réponse finale après avoir suivi les redirections, et s’arrête là. Il n’explore pas le site, n’évalue pas le JavaScript, ne teste pas votre configuration TLS et ne contrôle pas les attributs des cookies — et des chemins différents d’un même site peuvent renvoyer des en-têtes entièrement différents : vérifier la page d’accueil vous renseigne donc sur la page d’accueil.
Pour la configuration TLS en particulier, Qualys SSL Labs est l’outil de référence et il est exhaustif. Pour le certificat lui-même, celui-ci lit ce qu’un hôte présente réellement.
Questions sur les en-têtes
Pourquoi n’y a-t-il ni score ni note ?
Parce qu’une note est le seul résultat sur lequel personne ne peut agir. Savoir que vous avez un C ne vous dit rien sur l'en-tête manquant, pourquoi il est important pour votre site ou quoi définir - et cela encourage l'ajout d'en-têtes pour déplacer une lettre plutôt que pour résoudre un problème. Un site avec un CSP strict et aucune politique d'autorisations est en bien meilleure forme qu'un site avec six en-têtes définis sur des valeurs permissives, et aucune lettre ne peut exprimer cela. Ainsi, cela rapporte chaque en-tête séparément, juge la valeur que vous envoyez réellement et vous donne la ligne à ajouter.
Quel en-tête dois-je ajouter en premier ?
Strict-Transport-Security, si vous utilisez déjà HTTPS uniquement. Il s'agit d'une seule ligne, elle ne peut pas casser quoi que ce soit qui fonctionnait et elle ferme la fenêtre de rétrogradation lors de la première visite. Ensuite, Content-Security-Policy en mode rapport uniquement – c'est celui qui a de vraies dents, et le rapport uniquement vous permet de découvrir ce que votre site charge réellement avant d'appliquer quoi que ce soit. X-Content-Type-Options : nosniff est également gratuit et devrait simplement être activé.
Une politique de sécurité du contenu va-t-elle nuire à mon site ?
C’est possible, facilement, c’est pourquoi le mode rapport uniquement existe. Déployez Content-Security-Policy-Report-Only avec un collecteur, laissez-le pendant quelques semaines de trafic réel et lisez ce qu'il rapporte - vous trouverez des ressources que vous aviez oubliées, et fréquemment des éléments injectés en périphérie par un CDN ou un fournisseur d'analyse qui n'apparaissent dans aucun fichier source. Appliquez-le uniquement une fois que les rapports sont silencieux. L'application d'une politique écrite à partir d'une lecture de la base de code est la façon dont le paiement se déroule.
La protection X-XSS vaut-elle la peine d'être définie ?
Non. Il contrôlait un filtre XSS de navigateur qui a été supprimé de tous les principaux navigateurs – Chrome l'a abandonné en 2019 – et à son époque, le filtre lui-même a introduit des vulnérabilités, car il pouvait être manipulé pour casser des pages qui n'étaient pas vulnérables. Le définir sur 0 est défendable si certains scanners insistent ; le mettre à 1 ; mode=block répète des conseils qui ont expiré il y a des années. Content-Security-Policy est le remplacement.
Ai-je toujours besoin de X-Frame-Options si j’ai CSP ?
Non, à condition que votre CSP définisse des ancêtres de trame, qui le remplacent dans tous les navigateurs actuels. Ce vérificateur le reconnaît et ne signale pas les options X-Frame comme manquantes lorsque les ancêtres du cadre effectuent le travail. Conserver les deux ne coûte rien et n’aide qu’avec les navigateurs suffisamment anciens pour que vous ayez probablement des problèmes plus importants.
Un en-tête manquant signifie-t-il que je suis vulnérable ?
Non. Les en-têtes de sécurité constituent une défense en profondeur : ils limitent les dommages causés par une vulnérabilité, ils n’en créent ni ne suppriment une. Un site sans CSP n'est pas vulnérable à XSS ; un site avec un bug XSS l'est, et le CSP est ce qui empêche ce bug de devenir un compromis complet. L'ajout d'en-têtes est intéressant et peu coûteux, et cela ne remplace pas l'encodage de sortie, la validation d'entrée et la mise à jour des dépendances.
Dernière vérification . Vous avez repéré quelque chose de dépassé ? Dites-le-nous.