En-têtes de sécurité HTTP
Vérifiez si votre site a correctement configuré les en-têtes de sécurité HTTP.
Comment fonctionne la vérification des en-têtes
L'outil envoie une requête HTTPS GET ordinaire vers l'URL saisie et lit les en-têtes de la réponse - les mêmes en-têtes que reçoit chaque navigateur. Rien n'est analysé dans le corps de la page ; les en-têtes de sécurité résident entièrement dans la réponse HTTP.
Nous recherchons ensuite les en-têtes qui contrôlent les protections côté navigateur : Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options et Referrer-Policy. Chaque en-tête présent augmente le score, et les en-têtes manquants sont listés avec une explication du risque qu'ils laissent ouvert.
Comme la vérification suit les redirections, le résultat reflète l'URL finale. Si votre site redirige de HTTP vers HTTPS ou du domaine racine vers www, les en-têtes affichés appartiennent à la destination.
Comment lire les résultats
Le score est une orientation rapide, pas une certification. Ce qui compte en pratique :
- HSTS - indique aux navigateurs de toujours utiliser HTTPS pour votre domaine. Un max-age d'au moins six mois est une pratique courante ; ajoutez includeSubDomains uniquement si chaque sous-domaine sert HTTPS.
- CSP - la défense la plus forte contre les XSS, mais aussi la plus difficile à écrire. Même une politique basique limitant les sources de scripts est un grand progrès par rapport à rien du tout.
- X-Content-Type-Options: nosniff et X-Frame-Options (ou la directive CSP frame-ancestors) - des protections d'une seule ligne, peu coûteuses, contre le MIME sniffing et le clickjacking.
Problèmes fréquents
En-tête configuré, mais signalé comme manquant. Un reverse proxy ou un CDN devant votre application peut supprimer ou remplacer des en-têtes. Comparez la réponse via curl -I directement contre l'origine et contre l'URL publique pour trouver quelle couche le supprime.
CSP présente, mais inefficace. Content-Security-Policy-Report-Only journalise les violations sans rien bloquer. C'est utile pour les tests, mais n'offre aucune protection - passez à l'en-tête contraignant une fois votre journal de rapports propre.
Des routes différentes renvoient des en-têtes différents. Les en-têtes définis dans le middleware applicatif peuvent ne pas s'appliquer aux fichiers statiques servis directement par le serveur web, ni aux pages d'erreur. Testez aussi l'URL d'une ressource statique et une page 404.
Questions fréquentes
Quels en-têtes de sécurité chaque site web devrait-il avoir ?
Une base raisonnable : Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy et une protection contre le framing via X-Frame-Options ou CSP frame-ancestors. Les API bénéficient en plus de Cache-Control: no-store sur les réponses sensibles.
L'en-tête X-XSS-Protection est-il encore nécessaire ?
Non. Les navigateurs modernes ont supprimé l'auditeur XSS qu'il contrôlait, et dans les anciens navigateurs, cet en-tête pouvait même introduire des vulnérabilités. Utilisez plutôt une Content-Security-Policy stricte.
HSTS protège-t-il la toute première visite ?
Pas à lui seul - le navigateur n'apprend la règle qu'à partir de la première réponse HTTPS. Pour couvrir la première visite, soumettez votre domaine à la liste de préchargement HSTS (hstspreload.org) et utilisez la directive preload avec includeSubDomains.
Un mauvais en-tête peut-il casser mon site ?
Oui, deux cas classiques : une CSP trop stricte bloque vos propres scripts ou styles inline, et HSTS avec includeSubDomains casse tout sous-domaine qui fonctionne encore en HTTP simple. Déployez la CSP d'abord en mode report-only et démarrez HSTS avec un max-age court.
Suivez les changements d'en-têtes en continu
ePulz.io vous alerte lorsqu'un en-tête change (par exemple après un déploiement ayant supprimé CSP par erreur).
Commencer avec ePulz.io →À propos de cet outil
Les en-têtes de sécurité indiquent au navigateur comment protéger vos visiteurs. Cet audit vérifie si HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options et Referrer-Policy sont réellement présents et attribue une note au résultat, ce qui vous permet de repérer les failles de clickjacking et de MIME-sniffing après un déploiement.