Comment vérifier les en-têtes de sécurité HTTP de mon site (CSP, HSTS, X-Frame-Options…) ?
Dernière vérification : 30 octobre 2026
Pour vérifier les en-têtes de sécurité HTTP d'un site, lisez les en-têtes de réponse renvoyés par le serveur — via les outils de développement du navigateur, la commande curl, ou un scanner dédié — et comparez-les aux recommandations de MDN Web Docs pour chacun : Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options (progressivement remplacé par la directive frame-ancestors de CSP), X-Content-Type-Options, Referrer-Policy, et les attributs de sécurité des cookies (Secure, HttpOnly, SameSite). ScanMonSite analyse automatiquement l'ensemble de ces en-têtes via le moteur Mozilla HTTP Observatory.
Vérifiez les en-têtes de sécurité HTTP de votre site, en 30 secondes.
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Ce que le scan vérifie sur ce point :
- Analyse de l'ensemble des en-têtes de sécurité HTTP standard (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, en-têtes cross-origin, cookies) via le moteur Mozilla HTTP Observatory
- Vérification du forçage HTTPS et de la validité du certificat TLS
Vérifier manuellement en une commande
- Dans le navigateur : ouvrez les outils de développement (F12), onglet Réseau, rechargez la page, cliquez sur la requête principale (le document HTML) et consultez l'onglet En-têtes de réponse.
- En ligne de commande : curl -I https://example.com affiche uniquement les en-têtes de réponse, sans le corps de la page — remplacez example.com par votre propre domaine.
- Repérez les en-têtes Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options et Referrer-Policy dans la liste renvoyée.
Les en-têtes de sécurité HTTP les plus importants
| En-tête | Rôle | Ce qui se passe s'il est absent ou mal configuré |
|---|---|---|
| Content-Security-Policy (CSP) | Limite les sources de scripts, styles et autres ressources que le navigateur a le droit de charger — défense principale contre les failles XSS (source : MDN Web Docs) | Un script injecté par un attaquant peut s'exécuter comme n'importe quel script légitime du site |
| Strict-Transport-Security (HSTS) | Impose au navigateur de ne contacter le site qu'en HTTPS, même si l'utilisateur tape une adresse en http:// (source : MDN Web Docs) | La première connexion d'un visiteur reste exposée à une interception qui le renvoie vers une version HTTP non chiffrée |
| X-Frame-Options / frame-ancestors (CSP) | Détermine si la page peut être affichée dans un cadre (iframe) sur un autre site — protection contre le clickjacking (source : MDN Web Docs) | Un site tiers peut superposer des éléments invisibles sur le vôtre pour piéger un clic |
| X-Content-Type-Options | Empêche le navigateur de réinterpréter un fichier selon un type différent de celui déclaré par le serveur (source : MDN Web Docs) | Un fichier censé être inoffensif peut être exécuté comme du code par certains navigateurs |
| Referrer-Policy | Contrôle la quantité d'informations transmises dans l'URL d'origine lors d'un clic sortant vers un autre site (source : MDN Web Docs) | L'URL complète visitée par un internaute, parfois sensible, peut fuiter vers chaque site externe lié |
| Cookies : Secure / HttpOnly / SameSite | Trois protections indépendantes des cookies — transport chiffré, inaccessibilité en JavaScript, limitation aux requêtes du même site (source : MDN Web Docs) | Un cookie de session peut être intercepté en clair, lu par un script injecté, ou rejoué depuis un autre site |
Content-Security-Policy : le plus puissant, le plus facile à mal régler
CSP fonctionne par liste blanche : chaque type de ressource (scripts, styles, images, polices…) doit explicitement indiquer d'où il a le droit d'être chargé. MDN Web Docs décrit son usage principal comme une défense contre les attaques par script intersite (XSS), dans lesquelles un attaquant parvient à injecter du code malveillant dans le site d'une victime. La directive frame-ancestors, intégrée à CSP, couvre en plus la protection contre le clickjacking, et remplace progressivement X-Frame-Options.
Vérifiez vos en-têtes de sécurité HTTP
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
HSTS : interdire tout retour en HTTP
L'en-tête Strict-Transport-Security impose trois paramètres : max-age (durée en secondes pendant laquelle le navigateur retient la consigne), includeSubDomains (étend la règle à tous les sous-domaines) et preload (inscription dans les listes préchargées des navigateurs, qui protège même la toute première visite). Sans cet en-tête, un visiteur qui accède à votre site par une adresse en http:// reste exposé pendant le court instant qui précède la redirection vers https://.
Ce qu'un outil automatique ne remplace pas
Un scan confirme la présence et la structure générale d'un en-tête, pas la pertinence de chaque valeur qu'il contient. Un Content-Security-Policy peut être présent, syntaxiquement valide, et pourtant autoriser des domaines inutiles ou obsolètes qui affaiblissent sa protection réelle — seule une revue manuelle de chaque directive, ressource par ressource, permet de le confirmer.
Sources
Questions fréquentes
Quelle est la différence entre X-Frame-Options et la directive frame-ancestors de CSP ?
Les deux protègent contre le clickjacking en contrôlant qui peut afficher votre page dans un cadre (iframe). MDN Web Docs précise que frame-ancestors, une directive de Content-Security-Policy, offre des réglages plus fins et doit être privilégiée : X-Frame-Options reste supporté par les navigateurs, mais n'est plus l'option recommandée en premier.
Mon site est en HTTPS : ai-je encore besoin de HSTS ?
Oui. HTTPS protège une connexion déjà établie, mais sans HSTS, un visiteur qui tape votre adresse sans "https://" passe d'abord par une requête HTTP non protégée, exploitable par un attaquant positionné sur le réseau (source : MDN Web Docs).
Que se passe-t-il si mon CSP est mal configuré ?
Un CSP trop permissif n'apporte aucune protection réelle contre les scripts injectés (XSS), tandis qu'un CSP trop strict peut bloquer des ressources légitimes de votre propre site (polices, scripts tiers, images). Chaque directive doit être vérifiée une par une, pas seulement ajoutée.
Les attributs Secure, HttpOnly et SameSite d'un cookie protègent-ils contre la même chose ?
Non, chacun couvre un risque différent : Secure empêche l'envoi du cookie en clair sur HTTP, HttpOnly empêche sa lecture par un script JavaScript (XSS), SameSite limite son envoi lors de requêtes venant d'un autre site (CSRF) — source MDN Web Docs.
Un en-tête de sécurité absent est-il automatiquement une faille critique ?
Non. C'est un facteur de risque, pas une preuve d'exploitation : il affaiblit une protection en profondeur, sans garantir qu'une attaque précise réussira. La sévérité réelle dépend du contexte complet du site.
Puis-je vérifier ces en-têtes sans outil technique ?
Oui, depuis les outils de développement du navigateur (touche F12, onglet Réseau, cliquer sur la requête principale, onglet En-têtes) : tous les en-têtes de la réponse y sont listés, y compris ceux liés à la sécurité.
ScanMonSite vérifie-t-il la légitimité de chaque domaine autorisé dans mon CSP ?
Non. Le moteur Mozilla HTTP Observatory, utilisé par ScanMonSite, vérifie la présence et la structure générale de chaque en-tête de sécurité, pas la pertinence de chaque valeur qu'il contient — cette revue fine reste un travail manuel.
Pour aller plus loin
Vérifiez la configuration de votre site
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Votre site est déjà touché ? Demandez un devis de réparation.