Security

En-têtes HTTP

Affiche les en-têtes de réponse et audite les politiques de sécurité.

URL http or https (default https). Up to 3 redirects are followed.

Try: github.com cloudflare.com example.com mozilla.org

À propos de cet outil

HTTP Headers récupère votre URL avec une véritable requête HTTPS, capture chaque en-tête dans la réponse (et chaque réponse intermédiaire le long de toute chaîne de redirection), et fait passer le résultat par un audit de sécurité couvrant les en-têtes de durcissement modernes : Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy et Permissions-Policy. Chaque en-tête est vérifié pour la présence, la cohérence des valeurs et les écarts de bonnes pratiques.

Au-delà de l'audit, nous listons chaque en-tête textuellement afin que vous puissiez confirmer la politique de cache (Cache-Control, ETag, Vary), le traçage CDN (CF-Ray, X-Cache, X-Served-By), la compression (Content-Encoding: br/gzip) et tous les en-têtes personnalisés que votre pile émet. La méthode HTTP (GET ou HEAD), la version HTTP négociée (HTTP/1.1, HTTP/2, HTTP/3) et la version TLS sont rapportées dans la barre de requête.

Quand utiliser cet outil

Durcissement de la sécurité. Avant la mise en ligne, confirmez que HSTS, CSP et le reste sont définis avec des valeurs sûres — Mozilla Observatory baseline au minimum.
Débogage du cache. Voyez exactement ce que Cache-Control et Vary votre CMS ou framework émet — cause courante de "l'ancienne version reste collée".
Audits de chaîne de redirection. Repérez les chaînes accidentelles 302-puis-301, les boucles HTTP-vers-HTTPS-vers-hôte différent, et la canonicalisation manquante.
Comportement CDN. Confirmez que Cloudflare/Fastly/CloudFront met réellement en cache ce que vous pensez qu'il fait en lisant les en-têtes Age, X-Cache et spécifiques au CDN.

Ce que couvre notre audit de sécurité

Pour chacun des six en-têtes de durcissement, nous rapportons : présent ou manquant, la valeur réelle, et un verdict court ("bon", "besoin de resserrer", "vulnérable"). HSTS sans includeSubDomains, CSP avec unsafe-inline, ou Referrer-Policy laissé par défaut sont signalés. Nous ne vous disons jamais la politique "parfaite" car chaque site est différent — mais nous vous disons quels boutons sont encore au réglage d'usine.

Questions fréquentes

Qu'est-ce que HSTS et pourquoi est-ce important ?

Strict-Transport-Security indique au navigateur "utilisez toujours HTTPS pour ce domaine, même si l'utilisateur a tapé http:// ou cliqué sur un lien http://". Une fois défini avec un max-age raisonnable (typiquement 31536000 = 1 an), il empêche les attaques de dégradation SSL lors des visites ultérieures. L'ajout de includeSubDomains étend la protection à chaque sous-domaine — par défaut fort pour la plupart des sites mais assurez-vous que tous prennent vraiment en charge HTTPS d'abord.

Mon CSP est manquant — à quel point est-ce dangereux ?

Sans CSP, tout trou XSS dans votre site s'exécute avec une pleine puissance : il peut exfiltrer des cookies, charger des scripts contrôlés par l'attaquant ou réécrire le DOM. Un CSP de départ default-src 'self' bloque les charges utiles XSS les plus courantes (scripts inline, chargements de scripts externes) à un coût quasi nul. Des politiques plus strictes qui interdisent entièrement les scripts inline nécessitent une refactorisation mais fournissent une protection beaucoup plus forte.

Suivez-vous les redirections ?

Oui — jusqu'à cinq sauts. Chaque étape est affichée avec sa méthode, son statut, son emplacement et ses en-têtes afin que vous puissiez repérer les sauts à protocole mixte (HTTP→HTTPS), la canonicalisation manquante (apex vs www) ou les boucles accidentelles. La plupart des sites de production devraient rediriger au maximum une fois (HTTP → HTTPS), puis servir le contenu ; plus de deux sauts est généralement un signe de règles de réécriture qui se chevauchent.

Pourquoi l'outil affiche-t-il HTTP/2 même si j'ai configuré HTTP/3 ?

HTTP/3 (QUIC sur UDP) nécessite que le client accepte via l'en-tête Alt-Svc lors de la première connexion. Notre vérificateur utilise HTTP/2 sur TCP par défaut, ce que la plupart des clients HTTP font encore aujourd'hui ; si votre serveur annonce HTTP/3 dans Alt-Svc, vous verrez cet en-tête dans le résultat, mais la réponse elle-même est toujours sur HTTP/2. La présence de Alt-Svc est la bonne chose à rechercher.