Pourquoi analyser vos headers HTTP de sécurité ?
Les en-têtes HTTP de sécurité forment la première ligne de défense de votre site web côté navigateur. Sans CSP, sans HSTS, sans X-Frame-Options, vous laissez aux attaquants des angles d'attaque que les standards modernes savent fermer. Un test de sécurité site web régulier permet de détecter ces oublis avant qu'ils ne se transforment en incident.
Notre analyseur récupère les headers HTTP renvoyés par votre serveur, les confronte aux recommandations OWASP et Mozilla, puis calcule un score pondéré assorti d'une note de A à F. Vous obtenez en 30 secondes une vue claire des écarts à corriger.
Trois cas d'usage principaux :
- Audit de mise en production : valider la configuration des headers de sécurité avant ouverture publique
- Suivi de conformité : préparer un audit PCI DSS, ISO 27001 ou SOC 2 qui exige ces contrôles
- Réponse à incident : vérifier qu'aucun header HTTP critique n'a été retiré après une mise à jour serveur
Comment utiliser l'analyseur en 3 étapes
Étape 1 : saisir l'URL à tester
Renseignez l'URL complète à analyser, par exemple https://captaindns.com. L'outil accepte les URL publiques accessibles en HTTPS comme en HTTP, et suit la première redirection si nécessaire.
Étape 2 : lancer l'analyse des headers
Cliquez sur Analyser les headers. Le serveur effectue une requête GET vers l'URL, capture l'intégralité des en-têtes HTTP renvoyés, puis applique les règles de scoring sur les 10 security headers surveillés.
Étape 3 : lire la note et les recommandations
Vous obtenez :
- La note de A à F et le score sur 100
- Le détail header par header avec statut présent/absent
- Les valeurs recommandées pour chaque en-tête manquant
- Les tooltips pédagogiques expliquant le rôle de chaque header
Que sont les headers HTTP de sécurité ?
Un header HTTP est une ligne de métadonnée envoyée par le serveur en plus du contenu de la page. Les headers de sécurité sont une famille spécifique d'en-têtes qui pilotent le comportement du navigateur pour bloquer ou limiter les attaques côté client.
Quand votre navigateur charge https://captaindns.com, le serveur renvoie d'abord ses en-têtes HTTP avant le HTML. Ces headers indiquent par exemple : "Force le HTTPS pendant un an" (HSTS), "N'exécute que les scripts du même domaine" (CSP), ou "Refuse d'être affiché dans une iframe" (X-Frame-Options).
Exemple de headers HTTP renvoyés par un site sécurisé :
HTTP/2 200
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self'
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=()
Sans ces headers de sécurité, le navigateur applique des comportements par défaut beaucoup plus permissifs, hérités des débuts du web.
Les 10 headers analysés et leur rôle
L'outil évalue 10 headers HTTP, chacun avec un poids reflétant son impact sur la posture de sécurité.
| Header HTTP | Poids | Rôle | Exemple de valeur |
|---|---|---|---|
| Strict-Transport-Security | 2.0 | Force HTTPS et empêche le sslstrip | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | 2.0 | Bloque XSS et injection de scripts | default-src 'self'; script-src 'self' |
| Content-Security-Policy-Report-Only | 0.5 | CSP en mode observation, sans blocage | default-src 'self'; report-uri /csp-report |
| X-Frame-Options | 1.0 | Empêche le clickjacking via iframe | DENY ou SAMEORIGIN |
| X-Content-Type-Options | 1.0 | Bloque le MIME sniffing | nosniff |
| Referrer-Policy | 1.0 | Limite la fuite d'URL via Referer | strict-origin-when-cross-origin |
| Permissions-Policy | 1.0 | Restreint les API navigateur (caméra, micro, géoloc) | geolocation=(), microphone=() |
| Cross-Origin-Opener-Policy | 1.0 | Isole le contexte de navigation | same-origin |
| Cross-Origin-Embedder-Policy | 1.0 | Contrôle les ressources cross-origin chargées | require-corp |
| Cross-Origin-Resource-Policy | 1.0 | Définit qui peut charger vos ressources | same-origin ou same-site |
Total maximal : 11.5 points. Le score est ensuite ramené sur 100 pour produire la note finale.
Comment est calculée votre note de A à F ?
Le calcul applique une logique simple et reproductible.
Étape 1 : score brut
Chaque header présent et correctement configuré rapporte son poids complet. Un header présent mais mal configuré (ex : HSTS avec max-age trop court) rapporte un poids réduit. Le total brut maximum est de 11.5 points.
Étape 2 : conversion sur 100
Le score brut est ramené sur 100 par règle de trois : score = (brut / 11.5) × 100.
Étape 3 : attribution de la note
| Note | Score sur 100 | Interprétation |
|---|---|---|
| A | >= 90 | Posture excellente, conforme aux meilleures pratiques 2026 |
| B | >= 75 | Bonne configuration, quelques headers à compléter |
| C | >= 60 | Configuration partielle, headers critiques manquants |
| D | >= 40 | Posture faible, plusieurs headers de sécurité absents |
| F | < 40 | Aucune protection significative, action urgente recommandée |
À retenir : HSTS et CSP pèsent à eux deux 4 points sur 11.5, soit plus du tiers du score. Leur absence fait chuter mécaniquement la note d'au moins deux crans.
Cas d'usage concrets
Incident 1 : site noté F après refonte
Symptôme : après migration vers un nouveau framework, le site obtient F alors qu'il avait B avant la refonte.
Diagnostic : l'analyseur révèle l'absence de CSP, HSTS et X-Frame-Options. Les headers étaient ajoutés par l'ancien serveur Nginx, supprimés lors du passage à un hébergement managé qui ne les inclut pas par défaut.
Action : ajouter les headers de sécurité dans la configuration du nouveau framework (next.config.js, middleware Express, etc.) puis relancer l'analyse pour confirmer le retour à la note B ou A.
Incident 2 : audit de conformité bloqué
Symptôme : l'auditeur signale l'absence de headers de sécurité comme finding majeur, bloquant la certification PCI DSS.
Diagnostic : le test de sécurité site web confirme HSTS absent, CSP absent, Referrer-Policy non défini. Le serveur Apache sert la conf par défaut sans ajouts.
Action : configurer les directives Header set dans le vhost Apache, déployer en staging, lancer l'analyseur pour vérifier la note, puis pousser en production. Repasser le test pour fournir le rapport conforme à l'auditeur.
Incident 3 : clickjacking détecté en bug bounty
Symptôme : un chercheur en sécurité signale via bug bounty qu'il peut encadrer le tableau de bord client dans une iframe malveillante.
Diagnostic : l'analyseur montre X-Frame-Options absent et CSP sans directive frame-ancestors. Le navigateur autorise donc l'embedding par défaut.
Action : ajouter X-Frame-Options: DENY et frame-ancestors 'none' dans la CSP. Relancer l'analyse pour confirmer la fermeture de la faille et clôturer le ticket bug bounty.
FAQ - Questions fréquentes
Q : Qu'est-ce qu'un analyseur de headers HTTP ?
R : Un analyseur de headers HTTP est un outil qui inspecte les en-têtes renvoyés par un serveur web lors d'une requête. Il vérifie la présence et la configuration des headers de sécurité comme CSP, HSTS ou X-Frame-Options. Notre analyseur récupère ces en-têtes HTTP, évalue leur conformité aux bonnes pratiques OWASP, puis attribue une note de A à F. C'est la base d'un test sécurité site web complet et rapide.
Q : Quels headers de sécurité sont indispensables en 2026 ?
R : Les headers critiques en 2026 sont Content-Security-Policy (CSP) pour bloquer les scripts non autorisés, Strict-Transport-Security (HSTS) pour forcer HTTPS, X-Content-Type-Options pour empêcher le MIME sniffing, X-Frame-Options ou frame-ancestors CSP contre le clickjacking, et Referrer-Policy pour limiter la fuite d'URL. Permissions-Policy et Cross-Origin-Opener-Policy complètent une posture moderne. Sans ces headers HTTP, votre site reste exposé à des attaques connues.
Q : Quelle est la différence entre CSP et HSTS ?
R : CSP (Content-Security-Policy) contrôle les sources autorisées pour charger des scripts, styles, images ou iframes. Il protège contre le XSS et l'injection de contenu. HSTS (Strict-Transport-Security) force le navigateur à n'accéder au site qu'en HTTPS, empêchant les attaques de rétrogradation. CSP agit au niveau du contenu de la page, HSTS au niveau du transport. Les deux headers HTTP sont complémentaires et indispensables pour un score de sécurité élevé.
Q : Comment ajouter des headers de sécurité à mon site ?
R : L'ajout dépend de votre stack :
- Nginx : directives
add_headerdans le bloc server - Apache :
Header setdans .htaccess ou la conf vhost - Cloudflare : Transform Rules ou Workers
- Next.js :
headers()dans next.config.js - Express : middleware
helmet - Laravel : middleware dédié
Après déploiement, relancez l'analyse pour confirmer que les headers HTTP sont bien renvoyés.
Q : Des headers de sécurité manquants sont-ils une vulnérabilité ?
R : Des headers absents ne sont pas une vulnérabilité directe, mais ils suppriment des couches de défense. Sans CSP, une faille XSS devient pleinement exploitable. Sans HSTS, l'utilisateur reste vulnérable au sslstrip sur réseau hostile. Sans X-Frame-Options, votre site peut être encadré pour du clickjacking. Les auditeurs PCI DSS, ISO 27001 et SOC 2 considèrent ces headers HTTP comme des contrôles de sécurité attendus.
Q : Cet outil de test de sécurité site web est-il gratuit ?
R : Oui, notre analyseur de headers HTTP est entièrement gratuit, sans inscription ni limite d'usage. Lancez autant de tests de sécurité site web que nécessaire, sur n'importe quelle URL publique. Les résultats incluent la note de A à F, le détail de chaque header analysé et les recommandations de configuration. Aucune donnée n'est conservée au-delà du temps nécessaire au calcul du score.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Audit on-page complet | Analyser le HTML, les balises SEO et les ressources d'une page |
| Test HSTS | Vérifier l'en-tête Strict-Transport-Security et l'éligibilité à la preload list |
| Analyse de redirections | Suivre la chaîne de redirections HTTP et détecter les boucles |
| Détection de phishing | Vérifier si une URL est signalée comme phishing |
| Validation DNSSEC | Confirmer la signature cryptographique de votre zone DNS |
| Conformité MTA-STS | Vérifier la politique MTA-STS publiée pour votre domaine |
| Monitoring uptime | Surveiller la disponibilité de vos endpoints HTTP en multi-région |
Ressources utiles
- MDN - HTTP security headers (référence complète Mozilla)
- OWASP Secure Headers Project (recommandations OWASP)
- RFC 6797 - HTTP Strict Transport Security (spécification HSTS)
- MDN - X-Frame-Options (documentation X-Frame-Options)
- Content-Security-Policy Reference (référence CSP avec exemples)