Testez les Security Headers HTTP de n’importe quelle page : CSP, HSTS, framing, cookies, redirection depuis HTTP, intégrité des scripts et CORS. Chaque lacune est accompagnée de la modification exacte, chaque résultat d’un lien à partager. Gratuit, sans compte.
Les Security Headers HTTP sont des instructions qu’un serveur web envoie avec chaque réponse. Ils activent des protections dont le navigateur dispose déjà : quelles sources peuvent exécuter des scripts, si le site peut encore être chargé en HTTP non chiffré et si un autre site peut l’afficher dans un cadre. Sans eux, le navigateur revient à des réglages par défaut permissifs.
La vérification des Security Headers de reportedIP interroge une page comme le ferait un navigateur et lit ces en-têtes ainsi que les cookies, la redirection depuis http:// et les balises script de la page. Elle attribue une note de A+ à F, et chaque constat indique la modification qui le corrige.
Treize contrôles, classés selon ce qu’ils empêchent. Le poids est la part de chaque contrôle dans le score ; les contrôles de poids 0 sont affichés sans être notés.
| Contrôle | Ce qu’il empêche | Poids |
|---|---|---|
Content-Security-Policy |
Un script injecté qui s’exécute avec les droits de la page (cross-site scripting) | 25 |
Strict-Transport-Security (HSTS) |
La première requête d’une visite part en clair et peut être détournée | 20 |
X-Frame-Options / frame-ancestors |
Clickjacking : un autre site charge la page dans un cadre invisible | 15 |
X-Content-Type-Options |
Le navigateur devine le type d’un fichier et exécute un upload comme script | 15 |
HTTP → HTTPS redirect |
Le visiteur qui tape le domaine seul reste en HTTP non chiffré | 10 |
Cookies (Secure, HttpOnly, SameSite) |
Des cookies de session envoyés en HTTP ou lus par un script injecté | 10 |
Subresource Integrity (SRI) |
Un CDN compromis modifie les scripts que votre page charge | 10 |
Referrer-Policy |
Des URL complètes, paramètres compris, arrivent chez d’autres sites | 10 |
Permissions-Policy |
Du code intégré demande la caméra, le micro ou la position | 10 |
CORS (Access-Control-Allow-Origin) |
D’autres sites lisent la page avec la session du visiteur | 5 |
Server / X-Powered-By |
Des numéros de version précis placent le site sur la liste d’un scanner | 5 |
COOP / COEP / CORP |
Affiché, non noté : utile seulement pour l’isolation cross-origin | 0 |
TLS certificate |
Affiché, non noté : émetteur, expiration et protocole du certificat | 0 |
Pour aller plus loin sur chaque en-tête : le OWASP HTTP Headers Cheat Sheet et la référence des en-têtes de MDN.
Chaque contrôle obtient entre 0 et 100 points, multipliés par son poids. Une Content-Security-Policy absente coûte donc cinq fois plus qu’un serveur qui affiche sa version, ce qui correspond aux dégâts que chacun permet. Un contrôle qui ne s’applique pas sort du calcul au lieu de valoir zéro : HSTS sur une page servie en HTTP, les attributs de cookies sur une page sans cookies, la redirection quand rien n’écoute sur le port 80.
La note reprend les seuils de l’HTTP Observatory de Mozilla : A à partir de 90 points, A- à partir de 85, B+ à partir de 80, B à partir de 70, B- à partir de 65, C+ à partir de 60, C à partir de 50, C- à partir de 45, D+ à partir de 40, D à partir de 30, D- à partir de 25, F en dessous. A+ demande au moins 95 points et aucun constat défaillant. L’Observatory atteint A+ grâce à des points bonus au-delà de 100 et pondère certains constats autrement, si bien que les deux notes peuvent différer pour un même site.
Quand la Content-Security-Policy définit frame-ancestors, X-Frame-Options n’est plus nécessaire. La directive en est le successeur officiel, tous les navigateurs actuels la respectent et elle peut nommer les sites autorisés à intégrer la page. Deux cas ne comptent pas : une politique envoyée seulement en Report-Only, qui ne bloque rien, et frame-ancestors dans une balise meta, que les navigateurs ignorent.
Cette valeur demande au navigateur d’oublier que le site n’était accessible qu’en HTTPS (RFC 6797, section 6.1.1). Une checklist voit un en-tête présent et coche la case ; cette vérification le signale comme défaillant.
Les navigateurs doivent ignorer l’en-tête dans une réponse non chiffrée (RFC 6797, section 8.1). La vérification le sort donc du calcul au lieu d’ajouter ou de retirer des points.
Il arrive souvent que le serveur web et le CMS ajoutent tous deux le même en-tête. Des copies identiques sont lues comme une seule valeur : la vérification les accepte et signale seulement le doublon. Pour HSTS, seule la première copie compte (RFC 6797, section 8.1) : si la seconde contient includeSubDomains et pas la première, c’est la plus faible qui s’applique. X-Frame-Options avec DENY et SAMEORIGIN à la fois amène les navigateurs à refuser tout cadre, y compris ceux du site lui-même.
L’adresse est interrogée avec un GET normal, pas avec HEAD, car bon nombre de serveurs, de proxys et de pare-feu répondent à HEAD avec moins d’en-têtes. Jusqu’à trois redirections sont suivies. La requête porte un en-tête Origin provenant d’un domaine que personne n’autoriserait ; une page qui l’accepte quand même reprend donc n’importe quelle origine. Une seconde requête part vers http:// sur le même hôte pour voir où mène la première redirection, et une poignée de main TLS sur le port 443 lit le certificat.
De la page elle-même, seuls les 256 premiers Ko de HTML sont lus, pour les balises script et une Content-Security-Policy dans une balise meta. Rien du contenu n’est enregistré. Les cookies sont réduits à leur nom et à leurs attributs avant tout enregistrement ou affichage ; leurs valeurs sont supprimées.
Les résultats sont conservés une heure. Chaque vérification reçoit un lien de la forme /security-headers/?url=example.com qui affiche le résultat enregistré sans interroger le site à nouveau, et un résultat enregistré ne compte pas dans la limite quotidienne. Le bouton de nouvelle vérification récupère un résultat frais dès que celui enregistré a une minute.
La vérification s’exécute depuis notre serveur. Un site qui adapte ses en-têtes selon le pays, l’user agent ou l’état de connexion peut donc vous répondre autrement. Une seule page est lue : les en-têtes définis par le serveur web s’appliquent en général partout, mais une application peut en ajouter ou en retirer selon la route, d’où l’intérêt de vérifier à part la page de connexion ou de paiement. Les balises script insérées plus tard par JavaScript ne sont pas vues. L’outil ne peut pas dire si une politique est assez large pour que le site fonctionne, et pour TLS il indique la version choisie par le serveur, pas si des versions plus anciennes sont encore acceptées.