Vérificateur d'en-têtes de sécurité

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, Bitsight et RiskRecon les notent en continu, et ces résultats parviennent à vos clients lors des revues fournisseurs. Notre rapport 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.

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-Endpoints: default="https://<Endpoint-ID>.report.centralcsp.com", csp="https://<Endpoint-ID>.report.centralcsp.com"
Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"https://<Endpoint-ID>.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

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

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.

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.

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.

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.

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 et corriger les constats CSP de BitSight. Pour le changement de notation de juillet 2025 en particulier, voir pourquoi BitSight note désormais la CSP.

Si une revue de risque fournisseur de SecurityScorecard, Bitsight ou RiskRecon 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 depuis de vrais navigateurs, en continu.