Vérificateur d'En-têtes HTTP
Outil gratuit pour toute URL. Inspectez les en-têtes serveur, cache et sécurité (HSTS, CSP, X-Frame-Options) pour le développement, les tests et la revue sécurité.
Qu'est-ce que le Vérificateur d'En-têtes HTTP ?
Un Vérificateur d'En-têtes HTTP ouvre une connexion HTTP ou HTTPS réelle vers une URL et récupère les en-têtes de réponse que le serveur sert réellement. Les en-têtes HTTP sont la couche de métadonnées du protocole (RFC 7230 à 7237) et portent une quantité surprenante du comportement du serveur : comment le contenu est mis en cache, quels types de contenu sont autorisés, quelle politique cross-origin s'applique et, surtout, quels en-têtes de sécurité sont définis.
Les en-têtes de sécurité sont la partie qui intéresse le plus de monde. HSTS maintient un site en HTTPS, CSP restreint les scripts exécutables, X-Frame-Options bloque le clickjacking, et quelques autres protègent contre le MIME sniffing, la fuite de referrer et le downgrade de protocole. Cet outil envoie la requête, lit la réponse, note l'ensemble d'en-têtes de sécurité selon OWASP et Mozilla, et présente le reste des en-têtes pour que vous puissiez les parcourir.
Que Sont les En-têtes HTTP ?
Les en-têtes HTTP sont des composants fondamentaux de la communication web, servant de métadonnées qui contrôlent comment navigateurs et serveurs interagissent. Notre Vérificateur d'En-têtes HTTP se concentre sur les en-têtes de réponse, qui révèlent la configuration du serveur, la posture de sécurité et les paramètres de diffusion de contenu. Les en-têtes de réponse incluent des directives de sécurité (HSTS, CSP, X-Frame-Options), politiques de cache (Cache-Control, ETag), spécifications de contenu (Content-Type, Content-Length) et informations serveur (Server, X-Powered-By).
Les en-têtes HTTP fonctionnent de façon identique en connexions HTTP (port 80) et HTTPS (port 443), mais HTTPS ajoute le chiffrement TLS/SSL (RFC 8446) qui protège les en-têtes contre l'interception en transit. HTTPS est essentiel pour des en-têtes de sécurité comme HSTS, qui exigent spécifiquement des connexions HTTPS pour fonctionner efficacement. Il prend en charge les deux protocoles et gère automatiquement le chiffrement TLS/SSL pour les connexions HTTPS, garantissant une analyse d'en-têtes précise quel que soit le protocole.
Comment Fonctionne l'Analyse d'En-têtes HTTP
L'analyse d'en-têtes HTTP implique l'établissement de connexions réseau, la récupération de réponses HTTP, l'analyse des données d'en-têtes et l'évaluation des configurations de sécurité. Ce vérificateur utilise des méthodes faisant autorité basées sur les normes Internet pour fournir des informations d'en-têtes précises :
1. Établissement de Connexion et Résolution DNS
L'outil résout le nom de domaine cible en adresse IP via des requêtes DNS (enregistrements A/AAAA selon RFC 1035), puis établit une connexion TCP vers le port 80 (HTTP) ou 443 (HTTPS). Pour les connexions HTTPS, l'outil effectue une négociation TLS selon RFC 8446 pour établir une connexion chiffrée avant d'envoyer les requêtes HTTP.
Convertit les noms de domaine en adresses IP via des requêtes DNS (enregistrements A/AAAA) selon RFC 1035.
Établit une connexion TCP vers le port 80 (HTTP) ou 443 (HTTPS) pour la communication HTTP.
Effectue une négociation TLS/SSL selon RFC 8446 pour les connexions HTTPS afin d'établir une communication chiffrée.
Détecte automatiquement le protocole HTTP ou HTTPS depuis l'URL et gère le type de connexion approprié.
Prend en charge les adresses IPv4 et IPv6. Pour les adresses IP, l'outil ajoute automatiquement le protocole http:// et tente la connexion. Si HTTP échoue, HTTPS est essayé automatiquement en secours pour une compatibilité maximale.
La vérification de certificat SSL est volontairement désactivée, afin que vous puissiez inspecter les en-têtes sur des serveurs aux certificats auto-signés ou invalides. Pour évaluer le certificat lui-même, utilisez le Vérificateur SSL à la place.
Les requêtes ont un délai d'expiration de 15 secondes pour éviter une attente indéfinie. Si un serveur ne répond pas dans ce délai, la connexion est interrompue avec un message d'erreur approprié.
2. Transmission de Requête HTTP
L'outil envoie une requête HTTP (généralement GET ou HEAD) au serveur cible, incluant des en-têtes de requête standard tels que Host, User-Agent, Accept et Connection. Le serveur traite la requête et génère une réponse HTTP contenant codes de statut, en-têtes de réponse et éventuellement le contenu du corps de réponse.
Envoie une requête HTTP via GET ou HEAD pour récupérer efficacement les en-têtes de réponse. La méthode HEAD est préférée lorsque seuls les en-têtes sont nécessaires car elle ne télécharge pas le corps de réponse, ce qui est plus rapide et économe en bande passante.
Envoie des en-têtes de requête similaires à un navigateur incluant User-Agent (Chrome), Accept, Accept-Language, Accept-Encoding, Upgrade-Insecure-Requests, en-têtes Sec-Fetch-*, Cache-Control et Connection pour imiter un navigateur réel et garantir une récupération précise des en-têtes.
Reçoit la réponse HTTP contenant codes de statut, en-têtes de réponse et contenu de corps optionnel.
Gère les délais d'expiration, échecs DNS et erreurs HTTP avec des messages d'erreur appropriés et une dégradation gracieuse.
3. Analyse et Catégorisation des En-têtes de Sécurité
Les en-têtes de réponse HTTP récupérés sont analysés et catégorisés en en-têtes de sécurité, cache, contenu, informations serveur, CORS et en-têtes personnalisés. Chaque en-tête est validé pour conformité syntaxique selon RFC 7230-7237, et les en-têtes de sécurité sont analysés selon OWASP Secure Headers Project et les lignes directrices Mozilla.
Analyse les en-têtes de réponse HTTP selon RFC 7230-7237 et extrait noms et valeurs d'en-têtes.
Organise les en-têtes en catégories : Sécurité, Contenu, Cache, Infos Serveur, CORS et en-têtes personnalisés.
Reconnaît les alternatives modernes d'en-têtes, comme CSP frame-ancestors en remplacement de X-Frame-Options. L'outil analyse en-têtes traditionnels et modernes, privilégiant les implémentations modernes lorsque les deux sont présents.
Valide la syntaxe des en-têtes pour conformité aux normes HTTP selon RFC 7230-7237.
Analyse les en-têtes de sécurité selon les recommandations OWASP Secure Headers Project et les lignes directrices Mozilla.
Identifie les en-têtes de sécurité manquants indiquant des vulnérabilités et failles de sécurité potentielles.
Comment Utiliser le Vérificateur d'En-têtes HTTP
Notre Vérificateur d'En-têtes HTTP est conçu pour des utilisateurs de tous niveaux techniques. Suivez ce processus simple :
-
Étape 1 : Saisissez un nom de domaine (p. ex. example.com), une URL complète (p. ex. https://example.com) ou une adresse IP (IPv4 comme 192.168.1.1 ou IPv6 comme 2001:db8::1). L'outil détecte automatiquement le type de saisie et le protocole. Pour les domaines sans protocole, HTTPS est utilisé par défaut. Pour les adresses IP, HTTP est essayé en premier, avec HTTPS en secours si HTTP échoue.
-
Étape 2 : Complétez la vérification CAPTCHA pour garantir une utilisation sécurisée et prévenir les abus automatisés.
- Étape 3 : Cliquez sur le bouton « Vérifier les En-têtes ». L'outil établit une connexion HTTP et récupère les en-têtes.
Les résultats incluent les en-têtes de réponse HTTP complets organisés par catégorie (Sécurité, Contenu, Cache, Infos Serveur, CORS, Personnalisé), analyse des en-têtes de sécurité comparant les configurations aux recommandations OWASP, identification des en-têtes de sécurité manquants et recommandations de sécurité détaillées. Vous pouvez consulter les en-têtes en sections organisées, analyser les configurations de sécurité, copier les valeurs d'en-têtes ou exporter les résultats complets en JSON, CSV ou TXT.
Quels Sont les En-têtes de Sécurité Critiques ?
Les en-têtes de sécurité sont des en-têtes de réponse HTTP qui protègent sites web et utilisateurs de diverses attaques. Comprendre ces en-têtes est crucial pour maintenir des applications web sécurisées :
HTTP Strict Transport Security (HSTS)
En-tête :
Strict-Transport-Security (RFC 6797)Objectif : Force les navigateurs à utiliser des connexions HTTPS, prévenant les attaques de downgrade de protocole et man-in-the-middle.
Exemple :
Strict-Transport-Security: max-age=31536000; includeSubDomains
L'absence de HSTS permet aux attaquants de rétrograder les connexions HTTPS vers HTTP, interceptant des données sensibles. HSTS garantit que toutes les connexions utilisent le chiffrement, protégeant identifiants et informations personnelles.
Politique de Sécurité du Contenu (CSP)
En-tête : Content-Security-Policy (RFC 7762)
Objectif : Atténue les attaques Cross-Site Scripting (XSS) en contrôlant quelles ressources peuvent être chargées et exécutées.
Exemple : Content-Security-Policy: default-src 'self'; script-src 'self'
L'absence de CSP rend les sites vulnérables aux attaques XSS, permettant l'injection de scripts malveillants. CSP restreint le chargement de ressources, empêchant l'exécution non autorisée de scripts.
X-Frame-Options
En-tête :
X-Frame-Options (RFC 7034)Objectif : Prévient les attaques de clickjacking en contrôlant si les pages peuvent être affichées dans des cadres.
Valeurs :
DENY (pas de cadrage), SAMEORIGIN (même origine uniquement)Exemple :
X-Frame-Options: DENY
L'absence de X-Frame-Options permet aux attaquants d'intégrer des pages dans des cadres malveillants, trompant les utilisateurs pour cliquer sur des éléments cachés.
X-Content-Type-Options
En-tête :
X-Content-Type-Options: nosniffObjectif : Prévient les attaques de MIME-type sniffing en forçant les navigateurs à respecter les types de contenu déclarés.
L'absence de cet en-tête permet aux navigateurs de deviner les types de contenu, exécutant potentiellement du contenu malveillant comme scripts. La directive nosniff garantit que les navigateurs respectent les types MIME déclarés.
Referrer-Policy
En-tête : Referrer-Policy
Objectif : Contrôle la quantité d'informations de referrer partagées avec les requêtes, protégeant la confidentialité utilisateur.
Exemple : Referrer-Policy: strict-origin-when-cross-origin
Contrôle le partage d'informations de referrer, empêchant la fuite de paramètres URL sensibles vers des sites tiers.
X-XSS-Protection (Obsolète)
En-tête : X-XSS-Protection
Statut : Obsolète - les navigateurs modernes ont supprimé le filtrage XSS
Objectif : Servait à activer le filtrage XSS du navigateur, mais cette fonctionnalité a été supprimée des navigateurs modernes.
Alternative Moderne : Politique de Sécurité du Contenu (CSP) offre une protection XSS supérieure.
Ne comptez pas sur X-XSS-Protection. Implémentez plutôt une Content-Security-Policy stricte. CSP est la méthode moderne pour bloquer le Cross-Site Scripting et vous donne un contrôle fin sur les sources pouvant exécuter des scripts dans le navigateur.
Expect-CT (Obsolète)
En-tête : Expect-CT
Statut : Obsolète (RFC 9163) - remplacé par la surveillance Certificate Transparency
Objectif : Servait à détecter des certificats SSL mal émis via les journaux Certificate Transparency.
Note : Cet en-tête est obsolète et ne doit pas être utilisé. La surveillance moderne de certificats utilise directement les journaux Certificate Transparency.
N'implémentez pas Expect-CT. Utilisez plutôt des services de surveillance Certificate Transparency ou des outils interrogeant directement les journaux CT pour la surveillance et la sécurité des certificats.
Système de Notation des En-têtes de Sécurité
La note de sécurité est un score sur 100 points inspiré de securityheaders.com. Chaque en-tête est vérifié pour présence, qualité de configuration et alignement avec les bonnes pratiques actuelles :
Maximum 25 points. Score de base pour présence (6 points), bonus pour max-age ≥ 1 an (jusqu'à 20 points), directive includeSubDomains (+3 points) et directive preload (+2 points). Configuration excellente avec max-age ≥ 31536000, includeSubDomains et preload reçoit 25 points complets.
Maximum 25 points. Score de base pour présence (12 points), bonus pour directive default-src (+4 points), script-src (+3 points) et usage nonce/hash (+6 points). Pénalités pour unsafe-inline (-3 points) et unsafe-eval (-2 points). CSP excellente avec politiques strictes reçoit jusqu'à 25 points.
Maximum 12 points. DENY reçoit 12 points, SAMEORIGIN 10 points. CSP frame-ancestors est aussi reconnu comme alternative moderne et reçoit 12 points. Absence des deux reçoit 0 point.
Maximum 12 points. Configuration correcte avec « nosniff » reçoit 12 points. Absence ou mauvaise configuration reçoit 0 à 5 points.
Maximum 13 points. Configuration correcte avec valeurs de politique standard reçoit 13 points. Politiques plus strictes (strict-origin, strict-origin-when-cross-origin, same-origin, no-referrer) sont préférées.
Maximum 13 points. Score de base pour présence (5 points), bonus pour fonctionnalités restreintes (jusqu'à 8 points). Plus de fonctionnalités restreintes indiquent une meilleure configuration de sécurité.
Échelle de Notes des En-têtes de Sécurité Expliquée en Détail
Nous croyons en la transparence. Comprendre comment votre configuration d'en-têtes de sécurité se traduit en note vous aide à prendre des décisions éclairées sur la posture de sécurité de votre site. Voici le détail de notre système de notation :
Notes des En-têtes de Sécurité (7 niveaux)
Configuration d'en-têtes de sécurité quasi parfaite. Tous les en-têtes critiques sont présents et correctement configurés avec des paramètres optimaux. HSTS inclut max-age ≥ 1 an, includeSubDomains et preload. CSP utilise des politiques strictes avec nonces/hashes sans directives unsafe. Tous les autres en-têtes sont optimalement configurés. Cette note indique une implémentation de niveau entreprise.
Excellente configuration d'en-têtes de sécurité avec des axes d'amélioration mineurs. La plupart des en-têtes critiques sont présents et bien configurés. Peut avoir de légères lacunes comme CSP sans nonces/hashes, HSTS sans preload ou optimisations mineures. Cette note indique une implémentation solide adaptée à la production.
Bonne configuration d'en-têtes de sécurité avec marge d'amélioration. La plupart des en-têtes sont présents mais peuvent être sous-optimaux. Problèmes courants : CSP avec unsafe-inline ou unsafe-eval, HSTS avec max-age insuffisant ou en-têtes recommandés manquants comme Permissions-Policy. Cette note indique une sécurité acceptable nécessitant optimisation.
Configuration d'en-têtes de sécurité passable avec des lacunes significatives. Certains en-têtes critiques peuvent manquer ou être mal configurés. Problèmes courants : CSP manquante, HSTS faible ou absence de X-Frame-Options/X-Content-Type-Options. Cette note indique des mesures de base mais des améliorations critiques sont nécessaires.
Mauvaise configuration d'en-têtes de sécurité avec des failles majeures. Plusieurs en-têtes critiques manquent ou sont mal configurés. Les sites avec cette note sont vulnérables aux attaques courantes incluant XSS, clickjacking et downgrade de protocole. Action immédiate requise.
Très mauvaise configuration d'en-têtes de sécurité avec des vulnérabilités critiques. La plupart des en-têtes manquent ou sont gravement mal configurés. Les sites avec cette note sont très vulnérables et ne doivent pas être utilisés en production sans implémentation immédiate. Cette configuration pose des risques significatifs.
Configuration d'en-têtes de sécurité très mauvaise avec protection minimale ou nulle. Les en-têtes critiques sont totalement absents ou gravement mal configurés. Les sites avec cette note sont extrêmement vulnérables et ne doivent pas être déployés en production. Implémentation immédiate de tous les en-têtes critiques requise avant mise en ligne.
Bonnes Pratiques pour les En-têtes de Sécurité
Implémenter correctement les en-têtes de sécurité est crucial pour protéger sites web et utilisateurs des attaques. Cette section fournit des bonnes pratiques basées sur les recommandations OWASP et identifie les mauvaises configurations courantes :
Implémentez toujours HSTS avec un max-age approprié (minimum 31536000 secondes pour un an) et la directive includeSubDomains. L'absence de HSTS rend les sites vulnérables aux attaques de downgrade de protocole.
Implémentez des politiques CSP strictes limitant le chargement de ressources aux sources de confiance uniquement. Utilisez default-src 'self' comme base et évitez 'unsafe-inline' et 'unsafe-eval' lorsque possible. Des politiques CSP faibles avec ces directives offrent une protection minimale contre les attaques XSS.
Utilisez DENY pour empêcher tout cadrage, ou SAMEORIGIN pour autoriser uniquement le cadrage same-origin. Sinon, utilisez la directive Content-Security-Policy frame-ancestors (p. ex. frame-ancestors 'none' ou frame-ancestors 'self'), remplacement moderne de X-Frame-Options. CSP frame-ancestors offre un contrôle plus fin et est préféré à X-Frame-Options. L'absence de X-Frame-Options ou CSP frame-ancestors rend les sites vulnérables au clickjacking.
Définissez toujours nosniff pour prévenir les attaques de MIME-type sniffing. Cela garantit que les navigateurs respectent les types de contenu déclarés, évitant les attaques de confusion de type.
Supprimez ou minimisez l'en-tête Server pour éviter la divulgation d'informations. Révéler logiciel serveur et version (p. ex. Server: nginx/1.18.0) aide les attaquants à identifier des vulnérabilités et planifier des attaques ciblées.
Supprimez l'en-tête X-Powered-By pour éviter la divulgation du framework applicatif. Révéler des informations de framework (PHP, Express, etc.) aide les attaquants à identifier des vulnérabilités spécifiques. Supprimez cet en-tête en production.
Examinez les en-têtes X-* personnalisés pour la divulgation d'informations. Les en-têtes personnalisés peuvent révéler détails applicatifs internes, points de terminaison API ou architecture système. Supprimez ou assainissez les en-têtes divulguant des informations sensibles.
Implémentez une Referrer-Policy appropriée pour protéger la confidentialité utilisateur. Utilisez strict-origin-when-cross-origin pour un équilibre confidentialité/fonctionnalité, ou no-referrer pour une confidentialité maximale. Cela empêche la fuite de paramètres URL sensibles vers des sites tiers.
Utilisez des directives de cache appropriées : no-store pour contenu sensible, public, max-age=3600 pour ressources statiques et private pour contenu spécifique utilisateur. Des en-têtes Cache-Control mal configurés peuvent causer des problèmes de sécurité (mise en cache de contenu sensible) ou de performance.
Cas d'Usage Courants du Vérificateur d'En-têtes HTTP
Les raisons les plus courantes d'utiliser un vérificateur d'en-têtes :
Vérifiez l'implémentation des en-têtes de sécurité pour conformité aux recommandations OWASP, exigences PCI-DSS et normes de sécurité. Identifiez les en-têtes manquants indiquant des vulnérabilités et évaluez la posture de sécurité pour la gestion des risques.
Analysez les en-têtes de cache (Cache-Control, ETag, Expires) pour optimiser la diffusion de contenu et réduire la charge serveur. Identifiez les mauvaises configurations de cache impactant les performances et optimisez les politiques de cache.
Dépanez les problèmes CORS en analysant les en-têtes Access-Control-Allow-Origin et directives CORS associées. Identifiez les mauvaises configurations CORS empêchant les requêtes cross-origin et vérifiez les politiques CORS pour la conformité sécurité.
Vérifiez l'identification du logiciel serveur, analysez les en-têtes applicatifs personnalisés et identifiez les vulnérabilités de divulgation d'informations. Vérifiez les configurations d'en-têtes serveur selon les bonnes pratiques de sécurité.
Fonctionnalités et Capacités
Ce que vous obtenez, en un seul endroit. Utile pour les ingénieurs comme pour les utilisateurs non techniques :
Prend en charge les connexions HTTP (port 80) et HTTPS (port 443) avec gestion TLS/SSL appropriée selon RFC 8446, garantissant la compatibilité avec tous les serveurs web.
Établit des connexions HTTP en direct pour récupérer les informations d'en-têtes actuelles directement depuis les serveurs cibles, garantissant des données à jour et précises.
Analyse les en-têtes de sécurité selon OWASP Secure Headers Project et Mozilla, identifie les en-têtes manquants et fournit des recommandations de sécurité.
Organise les en-têtes en catégories logiques (Sécurité, Contenu, Cache, Infos Serveur, CORS, Personnalisé) pour une analyse et compréhension faciles.
Permet d'exporter les informations d'en-têtes en JSON (RFC 8259), CSV et TXT pour documentation, analyse et intégration avec d'autres systèmes.
Toutes les vérifications d'en-têtes sont effectuées en temps réel sans stockage, garantissant que vos informations restent privées et sécurisées. Nous ne conservons ni n'enregistrons noms de domaine, URL, en-têtes ou résultats de recherche.
Questions Fréquentes
La vérification d'en-têtes révèle ce que le serveur indique réellement aux clients : quels en-têtes de sécurité sont définis (et avec quelle rigueur), la politique de cache, le type de contenu déclaré, bannières d'identification serveur, règles CORS et en-têtes applicatifs personnalisés. Utile pour repérer des failles de sécurité, dépanner le comportement de cache, traquer un CDN mal configuré et confirmer les en-têtes attendus par votre programme de conformité.
Les en-têtes de sécurité protègent sites web et utilisateurs de diverses attaques incluant XSS (Cross-Site Scripting), clickjacking, MIME-type sniffing, attaques de downgrade de protocole et man-in-the-middle. Des en-têtes de sécurité manquants indiquent des vulnérabilités exploitables. Des en-têtes comme HSTS, CSP, X-Frame-Options et X-Content-Type-Options fournissent des couches de protection essentielles, prévenant les attaques web courantes et protégeant les données utilisateur.
Les en-têtes HTTP fonctionnent de façon identique en connexions HTTP (port 80) et HTTPS (port 443). HTTPS ajoute le chiffrement TLS/SSL (RFC 8446) à HTTP, protégeant les données d'en-têtes contre l'interception en transit. Des en-têtes comme HSTS sont conçus spécifiquement pour HTTPS, forçant les navigateurs à utiliser des connexions chiffrées. Le vérificateur prend en charge les deux protocoles et gère automatiquement le chiffrement TLS/SSL.
Non, notre Vérificateur d'En-têtes HTTP ne stocke pas de noms de domaine, URL, en-têtes HTTP ni résultats de recherche dans notre base applicative. Toutes les vérifications sont effectuées en temps réel uniquement pendant votre requête et immédiatement supprimées. Des journaux d'accès serveur standard peuvent toujours être créés comme décrit dans notre Politique de Confidentialité.
Les en-têtes HTTP peuvent révéler versions de logiciels serveur, frameworks applicatifs et détails personnalisés via Server, X-Powered-By et en-têtes X-* personnalisés. Cette divulgation d'informations peut aider les attaquants à identifier des vulnérabilités et planifier des attaques ciblées. Il identifie les en-têtes de divulgation d'informations et recommande de les supprimer ou minimiser pour éviter les fuites d'informations sensibles.