--- title: "Vérificateur d'en-têtes de sécurité HTTP - test gratuit" description: "Testez les en-têtes de sécurité HTTP d'un site : CSP, HSTS, X-Frame-Options, Permissions-Policy, cookies. Score sur 100 et correctif par constat. Gratuit." url: "https://centralcsp.com/fr/tools/security-headers/" lang: "fr" --- Outils # Vérificateur d'en-têtes de sécurité Entrez une URL et obtenez chaque en-tête de sécurité HTTP envoyé par votre site, noté sur 100 avec une liste de correctifs classés par sévérité. ### Analyser une URL Auditez les en-têtes de sécurité HTTP et les cookies d'un site, avec un score de durcissement et des correctifs priorisés. Suivre les redirections Analyser les en-têtes de sécurité Besoin d'analyser en profondeur uniquement la Content-Security-Policy ? [Utiliser le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/) Exemple de résultat ## Ce qu'un scan d'en-têtes vous donne Un score sur 100, les en-têtes exacts envoyés par le serveur, et un correctif attaché à chaque valeur signalée. Lancez le scanner ci-dessus pour voir les vôtres. 65 / 100 Les en-têtes de sécurité nécessitent attention Score de sécurité global ### Prochaines actions Remplacer 'unsafe-inline' dans script-src par des nonces ou des hachages Porter le max-age HSTS à au moins un an Ajouter une Permissions-Policy désactivant les fonctionnalités inutilisées du navigateur Ajouter Secure, HttpOnly et SameSite au cookie de session Sécurité Dans quelle mesure le site résiste aux attaques côté client. 58 /100 La configuration présente des lacunes de sécurité à corriger. Qualité Hygiène seule : coquilles, doublons, valeurs obsolètes. 84 /100 Globalement bien écrit, avec un peu de nettoyage restant : une valeur obsolète, une directive redondante. Rien de tout cela ne change le niveau de protection du site. * * * Les valeurs signalées sont teintées selon la sévérité. Sélectionnez-en une pour voir le problème, l'impact et le correctif à appliquer. content-security-policy[](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) default-src 'self' script-src 'self' 'unsafe-inline' https://js.example-cdn.com frame-ancestors 'none' strict-transport-security max-age=2592000 x-frame-options SAMEORIGIN x-content-type-options nosniff referrer-policy strict-origin-when-cross-origin x-xss-protection 1; mode=block * * * ### Constats et recommandations Problèmes et recommandations de qualité pour ces en-têtes de sécurité. ### script-src autorise 'unsafe-inline' La Content-Security-Policy autorise les scripts inline : toute injection de balisage devient une exécution de script. Ce seul mot-clé retire l'essentiel de la protection XSS qu'une CSP existe pour fournir. Élevé Sécurité Élevé Sécurité Recommandation Placez les scripts inline derrière des nonces par requête ou des hachages, puis ne listez que les origines de scripts que vos pages chargent réellement. Impact Un attaquant capable d'injecter du HTML n'importe où sur la page, un champ de commentaire, un écho de recherche, un template défaillant, peut exécuter du JavaScript arbitraire dans le navigateur de vos visiteurs et lire tout le contenu de la page, formulaires de paiement compris. ### Le max-age de Strict-Transport-Security est trop court La durée de vie HSTS est de 2592000 secondes, soit trente jours. Les navigateurs oublient vite l'ancrage HTTPS, et le site ne se qualifie pas pour le preload. Moyen Sécurité Moyen Sécurité Recommandation Portez max-age à au moins 31536000 (un an) et ajoutez includeSubDomains une fois que chaque sous-domaine sert du HTTPS. Impact Un visiteur qui n'a pas ouvert le site depuis trente jours peut être rétrogradé en HTTP simple par un attaquant sur le chemin réseau lors de sa prochaine première requête. ### Pas d'en-tête Permissions-Policy La réponse n'envoie aucune Permissions-Policy : la page et chaque iframe qu'elle contient gardent l'accès par défaut à des fonctionnalités puissantes du navigateur comme la caméra, le micro et la géolocalisation. Moyen Sécurité Moyen Sécurité Recommandation Envoyez une Permissions-Policy qui désactive les fonctionnalités que vos pages n'utilisent jamais, par exemple camera=(), microphone=(), geolocation=(). Impact Un script tiers compromis ou une iframe intégrée peut demander l'accès aux fonctionnalités de l'appareil au nom de votre origine. ### Le cookie de session n'a ni Secure, ni HttpOnly, ni SameSite Le cookie de session ne définit que Path. Sans Secure, il peut circuler en HTTP simple ; sans HttpOnly, tout script de la page peut le lire ; sans SameSite, il est joint aux requêtes cross-site. Moyen Sécurité Moyen Sécurité Recommandation Envoyez Set-Cookie: session=...; Path=/; Secure; HttpOnly; SameSite=Lax, et envisagez le préfixe \_\_Host- une fois le cookie limité à l'hôte. Impact Une XSS sur n'importe quelle page de l'origine peut lire le cookie de session et le rejouer, et une requête cross-site peut l'emporter sans action de l'utilisateur. ### X-XSS-Protection est déprécié Tous les navigateurs actuels ont retiré l'auditeur XSS que cet en-tête contrôlait. La valeur 1; mode=block ne fait rien dans les navigateurs modernes et permettait des fuites d'informations dans les anciens. Faible Qualité Faible Qualité Recommandation Supprimez l'en-tête ou envoyez X-XSS-Protection: 0, et appuyez-vous plutôt sur la Content-Security-Policy. Guide ## Comprendre les en-têtes de sécurité HTTP Les en-têtes de sécurité HTTP sont des en-têtes de réponse qu'un serveur envoie pour que le navigateur applique des protections sur la page ; ils se règlent dans la configuration du serveur, du CDN ou de l'edge, pas dans le code applicatif. Ils ne coûtent rien à envoyer, et ce sont les premiers éléments que vérifient un pentest, une plateforme de notation ou un attaquant. ### Pourquoi les en-têtes de sécurité comptent Chaque en-tête ferme une classe d'attaques que le navigateur autoriserait sinon. Une Content-Security-Policy contient le cross-site scripting en contrôlant ce qui peut se charger et s'exécuter. Strict-Transport-Security empêche la rétrogradation de protocole. La protection contre le framing bloque le clickjacking, X-Content-Type-Options empêche le MIME sniffing, Referrer-Policy garde les URL complètes hors des journaux des autres, et Permissions-Policy désactive les fonctionnalités du navigateur, comme la caméra ou le micro, que vos pages n'utilisent jamais. C'est aussi ainsi que l'extérieur vous juge. Les pentests signalent des en-têtes manquants dans presque chaque mission, et des plateformes de notation comme [SecurityScorecard](https://securityscorecard.com), [Bitsight](https://www.bitsight.com) et [RiskRecon](https://www.riskrecon.com) les notent en continu, et ces résultats parviennent à vos clients lors des revues fournisseurs. Notre [rapport State of the Web](https://centralcsp.com/fr/state-of-the-web/) mesure combien peu de sites en production envoient un jeu complet. Voici un exemple complet de configuration sécurisée : une réponse portant tous les en-têtes que ce vérificateur examine, aux valeurs qui obtiennent la note maximale. Copiez-la comme point de départ. Un en-tête ne se copie pas les yeux fermés, la Content-Security-Policy, car elle doit nommer ce que vos pages chargent réellement : conservez sa structure et remplacez les sources, en partant de vos constats de scan ou de [présentation de la CSP dans notre documentation](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy). Transport, contenu et cadrage Le socle de base. HTTPS est verrouillé, le sniffing est désactivé, les referrers sont réduits et toutes les fonctionnalités du navigateur que vos pages n'utilisent jamais sont coupées. ``` Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8 Referrer-Policy: strict-origin-when-cross-origin Cache-Control: no-store Cross-Origin-Resource-Policy: same-origin Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), midi=(), serial=(), bluetooth=(), hid=(), display-capture=(), screen-wake-lock=(), idle-detection=(), window-management=(), local-fonts=() ``` Reporting et application Là où le navigateur envoie ce qu'il observe, pour qu'un script bloqué ou une requête en échec vous parvienne au lieu de mourir dans la console de quelqu'un d'autre. ``` Reporting-Endpoints: default="https://.report.centralcsp.com", csp="https://.report.centralcsp.com" Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"https://.report.centralcsp.com"}]} NEL: {"report_to":"default","max_age":86400,"failure_fraction":1.0} Integrity-Policy: blocked-destinations=(script), endpoints=(default) Document-Policy: document-write=?0; report-to=default Connection-Allowlist: report-to=default ``` La Content Security Policy Gardez la structure et remplacez les sources par ce que vos pages chargent réellement. Le nonce est régénéré à chaque réponse. ``` Content-Security-Policy: default-src 'none'; script-src 'nonce-{RANDOM_PER_RESPONSE}' 'strict-dynamic' 'report-sha256'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; form-action 'self'; frame-ancestors 'none'; base-uri 'none'; object-src 'none'; worker-src 'self'; manifest-src 'self'; require-trusted-types-for 'script'; upgrade-insecure-requests; report-to csp ``` Cookies Uniquement sur les réponses qui en posent un. Le vérificateur lit ces trois attributs sur chaque Set-Cookie envoyé par votre site. ``` Set-Cookie: session=...; Path=/; Secure; HttpOnly; SameSite=Lax ``` ### En-têtes obligatoires Chaque page devrait les envoyer. Un en-tête manquant est un constat à lui seul, et ensemble ils portent l'essentiel du score. Les en-têtes de sécurité obligatoires et ce contre quoi chacun protège | En-tête | Ce contre quoi il protège | | --- | --- | | [Content-Security-Policy](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) | Le cross-site scripting, les scripts injectés et le clickjacking via frame-ancestors | | [Strict-Transport-Security](https://centralcsp.com/fr/docs/web-security/security-headers/strict-transport-security) | Le retour au HTTP et le vol de cookies sur le réseau | | [X-Content-Type-Options](https://centralcsp.com/fr/docs/web-security/security-headers/x-content-type-options) | Le MIME sniffing transformant un fichier téléversé en script | | [Content-Type](https://centralcsp.com/fr/docs/web-security/security-headers) | Les réponses ambiguës, quand le charset manque ou que le type ne correspond pas au corps | | [Set-Cookie attributes](https://centralcsp.com/fr/docs/web-security/security-headers/cookie-security) | Les cookies de session sans Secure, HttpOnly ou SameSite | ### En-têtes recommandés De la défense en profondeur. Chacun couvre une brèche plus étroite que l'ensemble obligatoire, et un site qui les envoie tous obtient la note maximale. Les en-têtes de sécurité recommandés et ce contre quoi chacun protège | En-tête | Ce contre quoi il protège | | --- | --- | | [Referrer-Policy](https://centralcsp.com/fr/docs/web-security/security-headers/referrer-policy) | La fuite d'URL complètes et de leurs paramètres vers des tiers | | [Permissions-Policy](https://centralcsp.com/fr/docs/web-security/policies/permissions-policy) | L'accès caméra, micro, géolocalisation et paiement que vos pages n'utilisent jamais | | [Cross-Origin-Resource-Policy](https://centralcsp.com/fr/docs/web-security/security-headers/cross-origin-resource-policy) | L'intégration de vos ressources par d'autres sites | | [Cross-Origin-Opener-Policy](https://centralcsp.com/fr/docs/web-security/policies/cross-origin-opener-policy) | Les attaques entre fenêtres, et le prérequis à l'isolation cross-origin | | [Cross-Origin-Embedder-Policy](https://centralcsp.com/fr/docs/web-security/policies/cross-origin-embedder-policy) | L'intégration de ressources qui ne l'ont jamais accepté | | [Cache-Control](https://centralcsp.com/fr/docs/web-security/security-headers/cache-control) | Les réponses sensibles ou authentifiées mises en cache là où elles ne devraient pas l'être | | [Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) | Les violations que le navigateur génère et abandonne en silence, faute de destination | | [NEL](https://centralcsp.com/fr/docs/web-security/policies/network-error-logging) | Les échecs DNS, TLS et de connexion que votre serveur ne voit jamais | | [Integrity-Policy](https://centralcsp.com/fr/docs/web-security/policies/integrity-policy) | Les scripts chargés sans Subresource Integrity, partout sur le site | | [Document-Policy](https://centralcsp.com/fr/docs/web-security/policies/document-policy) | Les comportements de document à désactiver, comme document.write | | [Connection-Allowlist](https://centralcsp.com/fr/docs/web-security/policies/connection-allowlist) | Les sorties réseau vers des origines que vous n'avez jamais approuvées | ### En-têtes hérités Remplacés par mieux. Les envoyer n'est pas une erreur, mais c'est le remplaçant moderne que le score récompense. Les en-têtes de sécurité hérités et ce qui les remplace | En-tête | Pourquoi il est hérité | | --- | --- | | [X-Frame-Options](https://centralcsp.com/fr/docs/web-security/security-headers/x-frame-options) | Le clickjacking, remplacé par frame-ancestors en CSP. À ne garder que pour de très anciens navigateurs | | [Report-To](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/report-to) | Remplacé par Reporting-Endpoints, mais toujours requis pour livrer les rapports NEL | ### En-têtes dépréciés Retirez-les. Chacun est retiré des standards, et l'envoyer ajoute des octets à chaque réponse sans ajouter de protection. Les en-têtes de sécurité dépréciés à retirer | En-tête | Ce contre quoi il protège aujourd'hui | | --- | --- | | [X-XSS-Protection](https://centralcsp.com/fr/docs/web-security/security-headers/deprecated-headers) | Rien. L'auditeur XSS du navigateur qu'il pilotait a été retiré, et l'activer provoquait des fuites | | [Expect-CT](https://centralcsp.com/fr/docs/web-security/security-headers/deprecated-headers) | Rien. La Certificate Transparency est appliquée par défaut par les navigateurs | | [Public-Key-Pins](https://centralcsp.com/fr/docs/web-security/security-headers/deprecated-headers) | Rien. Le pinning a été retiré des navigateurs et pouvait vous verrouiller hors de votre propre site | | [Feature-Policy](https://centralcsp.com/fr/docs/web-security/security-headers/deprecated-headers) | Rien. Renommé en Permissions-Policy | ### Comment lire vos résultats Chaque constat nomme l'en-tête, dit ce qui ne va pas et vous donne la valeur exacte à servir à la place. Un en-tête manquant ? Signalé. Une valeur qui affaiblit la protection ? Signalée aussi. Et comme les en-têtes vivent dans la configuration de votre serveur, CDN ou edge, la plupart des correctifs tiennent en une ligne : déployez, relancez le scan, regardez le constat disparaître. ### Ce que signifie votre score 80 et au-dessus, l'ensemble d'en-têtes est solide. De 50 à 79, il demande de l'attention : les en-têtes sont globalement présents mais au moins une valeur en fait moins qu'il n'y paraît. En dessous de 50, il y a des lacunes critiques, en général une Content-Security-Policy absente ou un en-tête HSTS qui expire trop vite pour compter. Le score est sur 100 et se divise en deux parties. Le score de sécurité pèse la protection réelle apportée par chaque valeur ; le score de qualité pèse la propreté d'écriture de l'ensemble. C'est aussi pourquoi ce chiffre peut diverger de la note en lettre, de A+ à F, que donnent d'autres scanners : une note en lettre récompense surtout la présence, si bien qu'un site qui envoie tous les en-têtes peut obtenir un A ailleurs et rester vers 60 ici parce que deux de ces en-têtes portent des valeurs qui ne protègent presque rien. ### Comparaison avec securityheaders.com et le MDN HTTP Observatory Ces deux outils sont gratuits et constituent tous deux un bon premier aperçu. La différence tient à ce qui se passe après la vérification. securityheaders.com et le MDN HTTP Observatory sont pour l'essentiel des contrôles de présence qui renvoient une note en lettre : ils vous disent qu'un en-tête manque. Ce vérificateur lit aussi la valeur : un en-tête présent mais faible devient un constat plutôt qu'une réussite, et le résultat est un score sur 100 avec chaque constat classé par sévérité, un scénario d'exploitation, la valeur exacte à déployer à la place, et un export CSV ou PDF. C'est aussi pourquoi les chiffres divergent. Un site qui envoie tous les en-têtes avec des valeurs médiocres obtient un bon résultat sur un contrôle de présence et se situe vers 60 ici. Aucune des deux lectures n'est fausse : elles répondent à des questions différentes. ### Corriger un constat SecurityScorecard, Bitsight ou RiskRecon Deux guides pas à pas couvrent les constats que ces plateformes remontent le plus souvent : [corriger les constats CSP de SecurityScorecard](https://centralcsp.com/fr/blog/fix-securityscorecard-csp-findings) et [corriger les constats CSP de BitSight](https://centralcsp.com/fr/blog/fix-bitsight-csp-findings). Pour le changement de notation de juillet 2025 en particulier, voir [pourquoi BitSight note désormais la CSP](https://centralcsp.com/fr/blog/bitsight-rau25-was-csp). Si une revue de risque fournisseur de [SecurityScorecard](https://securityscorecard.com), [Bitsight](https://www.bitsight.com) ou [RiskRecon](https://www.riskrecon.com) vous a remis un constat du type "Content Security Policy (CSP) Missing", le correctif est vérifiable depuis chez vous. Ces plateformes notent ce que montrent vos réponses HTTP publiques, sans agent ni identifiant : corrigez les en-têtes à votre edge, et leur prochaine observation de votre site verra la réponse conforme. Scannez exactement le nom d'hôte cité dans le constat, en suivant les redirections : l'apex, une redirection www et un sous-domaine peuvent tous répondre avec des en-têtes différents, ce qui explique la plupart des tickets « mais la page d'accueil a bien une CSP ». Appliquez les corrections, relancez le scan pour confirmer, puis utilisez le flux de résolution ou de rescan de la plateforme. Une réserve que nous ne cacherons pas : les modèles de notation sont propriétaires, donc une correction ferme le constat mais personne ne peut promettre un score précis. Pour garder le constat clôturé entre deux revues, [CentralCSP surveille votre politique](https://centralcsp.com/fr/platform/monitoring/) depuis de vrais navigateurs, en continu. Pour aller plus loin - [Fondamentaux de la sécurité web](https://centralcsp.com/fr/docs/web-security) - [Présentation de Content-Security-Policy](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) - [Référence des en-têtes de sécurité](https://centralcsp.com/fr/docs/web-security/security-headers) - [L'en-tête Strict-Transport-Security](https://centralcsp.com/fr/docs/web-security/security-headers/strict-transport-security) - [Améliorer la note de vos en-têtes de sécurité](https://centralcsp.com/fr/blog/improve-security-headers-grade) - [Les en-têtes de sécurité hérités à retirer](https://centralcsp.com/fr/blog/legacy-security-headers-to-retire) Plus d'outils gratuits ## Poursuivez l'audit avec les autres outils gratuits Chaque outil est gratuit, fonctionne sans compte et note avec la même échelle de sévérité. ### Scanner CSP Récupérez la Content-Security-Policy réellement servie par une URL et notez-la face aux contournements connus, aux sources joker et aux directives manquantes. - Constats au niveau des directives - Lien de résultats partageable [Lancer le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/) ### Évaluateur CSP Collez une politique pas encore déployée et obtenez la même notation et les mêmes constats qu'un scan en ligne, sans URL. - Auditez avant de déployer - Même moteur de notation [Évaluer une politique dans l'évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/) ### Vérificateur Reporting API Vérifiez que le signalement des violations fonctionne vraiment : les endpoints, Reporting-Endpoints et Report-To, et quelles fonctionnalités de sécurité rapportent réellement. - Cartographie des endpoints et fonctionnalités - Pertes silencieuses signalées [Vérifier votre configuration Reporting API](https://centralcsp.com/fr/tools/reporting-api/) ### Générateur de hash SRI Transformez l'URL d'un script ou d'un CSS servi par un CDN en hash Subresource Integrity, avec une balise prête à coller et une vérification CORS. - SHA-256, 384 et 512 - CORS vérifié pour vous [Générer un hash SRI](https://centralcsp.com/fr/tools/sri-hash/) ### Générateur de hash CSP Transformez un script ou un style inline en hash qui l'autorise sous une politique stricte, directement dans votre navigateur. - Fonctionne entièrement côté client - SHA-256, 384 et 512 [Générer un hash CSP](https://centralcsp.com/fr/tools/csp-hash/) ### Comparateur de sites Situez votre score : votre site à côté de la moyenne du jeu de données et des sites les mieux configurés de l'année, contrôle par contrôle. - Références publiées et vérifiables - Vue radar par catégorie [Comparez votre site aux meilleurs](https://centralcsp.com/fr/tools/compare/) FAQ ## Questions fréquentes En-têtes, scores, scanners et notations : les réponses. ### Que sont les en-têtes de sécurité HTTP ? Les en-têtes de sécurité HTTP sont des en-têtes de réponse envoyés par le serveur pour que le navigateur applique des protections à la page : Content-Security-Policy restreint ce qui peut se charger et s'exécuter, Strict-Transport-Security force le HTTPS, X-Frame-Options et frame-ancestors bloquent le clickjacking, X-Content-Type-Options empêche le MIME sniffing, Referrer-Policy limite les URL divulguées aux autres sites, et Permissions-Policy désactive les fonctionnalités inutiles du navigateur. Ils se configurent côté serveur, CDN ou edge, pas dans le code applicatif. ### Quels en-têtes de sécurité un site doit-il envoyer en 2026 ? Cinq sont obligatoires : une Content-Security-Policy, Strict-Transport-Security avec un max-age d'au moins 31536000 et includeSubDomains, X-Content-Type-Options: nosniff, un Content-Type portant un charset, et Secure, HttpOnly et SameSite sur chaque cookie. Le clickjacking se traite par la directive frame-ancestors de la politique, pas par X-Frame-Options, désormais hérité. Recommandés en complément : Referrer-Policy, Permissions-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cache-Control, et l'ensemble reporting (Reporting-Endpoints, NEL, Integrity-Policy, Document-Policy). X-XSS-Protection, Expect-CT, Public-Key-Pins et Feature-Policy sont dépréciés : retirez-les. ### Qu'est-ce qu'un bon score d'en-têtes de sécurité ? 80 sur 100 et au-dessus, l'ensemble d'en-têtes est solide ; de 50 à 79, il demande de l'attention ; en dessous de 50, il y a des lacunes critiques. Le score couvre à la fois les constats de sécurité, c'est-à-dire la protection réellement apportée par chaque valeur, et les constats de qualité, c'est-à-dire la propreté de l'ensemble. Les poids les plus lourds portent sur la Content-Security-Policy et sur Strict-Transport-Security : les trois actions qui font le plus bouger le chiffre sont donc de déployer une politique sans 'unsafe-inline', de régler HSTS sur max-age=31536000 avec includeSubDomains, et d'ajouter X-Content-Type-Options: nosniff. ### Ce vérificateur d'en-têtes de sécurité est-il gratuit ? Oui. Pas de compte, pas d'e-mail exigé, et les résultats restent consultables : ils vivent à une URL partageable et s'exportent en CSV ou PDF. Le scan part de nos serveurs vers l'URL saisie, il refuse donc les adresses privées et internes, et vous pouvez relancer un scan à tout moment après un correctif. ### En quoi est-ce différent de securityheaders.com ? securityheaders.com vérifie la présence d'une courte liste d'en-têtes et attribue une note en lettre ; c'est un bon premier regard. Ce vérificateur analyse les valeurs : la Content-Security-Policy directive par directive, les attributs des cookies, les réglages dépréciés ou contradictoires. Chaque constat reçoit une sévérité et un correctif concret, les constats de sécurité incluent un scénario d'exploitation, et les résultats s'exportent en CSV et PDF pour un ticket ou un dossier d'audit. Les deux outils sont gratuits. ### Pourquoi SecurityScorecard ou Bitsight signale-t-il mon site alors qu'un autre vérificateur le valide ? Parce qu'ils jugent la qualité des valeurs et l'ensemble de votre parc, pas la présence d'en-têtes sur une seule page. SecurityScorecard évalue l'URL finale de la chaîne de redirections et scanne chaque sous-domaine de votre empreinte numérique. Depuis juillet 2025, le vecteur Web Application Security de Bitsight charge les pages dans un vrai navigateur : une Content-Security-Policy présente mais permissive échoue, même si un test de présence passe. Scannez le nom d'hôte exact cité dans le constat, redirections suivies, pour voir ce que leur scanner a vu. ### Des en-têtes de sécurité manquants sont-ils vraiment une vulnérabilité ? Isolés, ils constituent généralement un constat de faible sévérité en pentest : de la défense en profondeur plutôt qu'une faille directe. Ils coûtent pourtant sur trois plans. Une faille XSS ou de clickjacking qu'une politique aurait contenue devient pleinement exploitable. Les plateformes de notation et les questionnaires fournisseurs les signalent à vos clients. Et pour les pages de paiement, PCI DSS v4 exige de surveiller les en-têtes tels que reçus par le navigateur du consommateur (exigence 11.6.1) : leur absence devient un écart de conformité, pas seulement de durcissement. ### Les en-têtes de sécurité ont-ils un impact SEO ? Pas directement : aucun en-tête de sécurité n'est un facteur de classement, et en ajouter un ne fera pas bouger une position à lui seul. Deux effets indirects sont néanmoins réels. Strict-Transport-Security soutient le HTTPS, que Google utilise comme signal léger. Et une Content-Security-Policy trop stricte peut bloquer vos propres scripts, styles ou polices, ce qui casse le rendu et se voit dans les Core Web Vitals : une politique déployée sans phase report-only peut donc vous coûter là où les en-têtes eux-mêmes ne coûteraient rien. ## Un scan montre aujourd'hui. La surveillance montre tous les jours suivants. CentralCSP collecte les rapports Content-Security-Policy depuis les navigateurs de vos vrais visiteurs et vous alerte quand une politique casse ou qu'un script inconnu apparaît : les en-têtes que vous venez de corriger le restent. Ajoutez un en-tête, sans changer le code. [Commencer avec CentralCSP](https://app.centralcsp.com) [Voir la surveillance continue des en-têtes](https://centralcsp.com/fr/platform/monitoring/) --- Disponible en : [en](https://centralcsp.com/en/tools/security-headers/), [fr](https://centralcsp.com/fr/tools/security-headers/)