Inspectez les en-têtes de réponse, redirections et sécurité
DNS et enregistrements
Lookup DNS Tous les enregistrements DNS d'un domaine Lookup d'enregistrement A Adresses IPv4 d'un domaine Lookup d'enregistrement AAAA Adresses IPv6 d'un domaine Lookup MX Serveurs de messagerie d'un domaine Lookup NS Serveurs de noms faisant autorité Lookup TXT Enregistrements TXT, SPF, vérification Lookup CNAME Enregistrements de nom canonique (alias) Lookup SOA Enregistrement Start of Authority Lookup SRV Enregistrements de localisation de service Lookup CAA Quelles CA peuvent émettre des certificats DNS inversé (PTR) Adresse IP vers nom d'hôte Vérification DNSSEC Le domaine est-il signé et validé ? Diagnostic DNS Un bilan complet de délégation et de DNSDélivrabilité des e-mails
Vérification SPF Validez votre enregistrement Sender Policy Framework Vérification DMARC Inspectez et évaluez votre politique DMARC Vérification DKIM Trouvez et validez votre clé publique DKIM Vérification de liste noire Vérifiez une IP face aux listes de blocage e-mail (DNSBL) Test SMTP Connectez-vous à un serveur de messagerie et vérifiez STARTTLS Vérification MTA-STS Politique TLS imposée pour le courrier entrant Vérification BIMI Enregistrement de logo de marque pour l'e-mail Vérification TLS-RPT Politique de rapport TLS SMTPRéseau et web
Vérification de certificat SSL Inspectez le certificat TLS d'un site et son expiration Vérification des en-têtes HTTP Inspectez les en-têtes de réponse, redirections et sécurité Ping (TCP) Accessibilité et latence via TCP Vérification de ports Quels ports courants sont ouvertsDomaine
Lookup WHOIS Données d'enregistrement pour domaines, IP et ASNLes en-têtes de réponse HTTP révèlent le comportement d'un serveur web : le code de statut qu'il renvoie, vers où il redirige, quel logiciel il exécute et quels en-têtes de durcissement de sécurité il envoie. L'absence d'en-têtes comme HSTS, Content-Security-Policy ou X-Frame-Options expose les sites aux attaques par rétrogradation, par injection et par clickjacking. IPeek suit toute la chaîne de redirections et évalue la réponse au regard des principaux en-têtes de sécurité.
Chaque réponse HTTP commence par un code de statut et un ensemble d'en-têtes, avant le corps de la page. Le code de statut indique au client ce qui s'est passé : 200 signifie un succès, 301 et 302 signalent que la ressource a été déplacée, 404 indique qu'elle est introuvable, et 5xx qu'une erreur est survenue côté serveur. Les en-têtes transportent des métadonnées telles que Content-Type, Server, Cache-Control ainsi que les directives de sécurité qui indiquent au navigateur comment traiter la page. IPeek interroge l'URL, capture ces en-têtes exactement tels que le serveur les a envoyés, et suit chaque redirection pour vous montrer le chemin complet jusqu'à la réponse finale.
Vérifiez d'abord que le code de statut final correspond à celui attendu, généralement 200 pour une page en ligne. Parcourez ensuite la chaîne de redirections : une configuration propre redirige HTTP vers HTTPS et tout hôte non canonique vers l'hôte canonique en un minimum de sauts, car chaque redirection supplémentaire ajoute de la latence. Surveillez les boucles de redirection ou les chaînes qui aboutissent sur le mauvais hôte. L'en-tête Server révèle le logiciel utilisé, et la note de sécurité des en-têtes indique d'un coup d'œil quels en-têtes de protection sont présents et lesquels manquent.
Strict-Transport-Security (HSTS) force les navigateurs à utiliser HTTPS, ce qui empêche les attaques par rétrogradation. Content-Security-Policy restreint les sources depuis lesquelles les scripts et les ressources peuvent être chargés : c'est la meilleure défense contre le cross-site scripting. X-Frame-Options ou la directive frame-ancestors d'une CSP bloque le clickjacking en contrôlant qui peut intégrer votre page. X-Content-Type-Options: nosniff empêche le reniflage de type MIME. La lacune la plus courante est un site qui n'envoie aucun de ces en-têtes, laissant le navigateur sans protection supplémentaire. Ajoutez-les au niveau du serveur web ou du CDN, puis revérifiez qu'ils apparaissent bien dans la réponse en ligne.
Vérifiez les en-têtes après un déploiement, après un changement de CDN ou de reverse proxy, et chaque fois que vous renforcez la posture de sécurité d'un site, car ce sont les moments où des en-têtes sont ajoutés, supprimés ou écrasés. C'est le moyen le plus rapide de confirmer qu'une redirection HTTP vers HTTPS fonctionne réellement, de déboguer une chaîne de redirections inattendue, ou de vérifier qu'un en-tête de sécurité que vous avez configuré atteint bien les navigateurs réels au lieu d'être supprimé quelque part dans la chaîne de distribution.
Elle affiche le code de statut, la chaîne de redirections, le logiciel serveur et les en-têtes de sécurité renvoyés par un site. Vous voyez si l'URL redirige correctement, combien de sauts cela nécessite, quel serveur répond, et quels en-têtes de protection comme HSTS et Content-Security-Policy sont présents ou manquants. C'est donc un diagnostic rapide à la fois pour les problèmes de routage et pour les failles de sécurité.
HTTP Strict-Transport-Security est un en-tête qui demande aux navigateurs de se connecter uniquement en HTTPS pendant une durée définie. Il est important car il empêche les attaques par rétrogradation et de type man-in-the-middle, où un attaquant force une connexion HTTP non sécurisée. Une fois que le navigateur a vu HSTS, il refuse toute connexion HTTP en clair vers cet hôte jusqu'à l'expiration de la politique, fermant ainsi une véritable fenêtre d'attaque.
Les chaînes de redirections s'accumulent généralement lorsque des règles distinctes corrigent chacune un seul point : HTTP vers HTTPS, non-www vers www, et normalisation du slash final. Chaque saut ajoute de la latence et un risque d'erreur. Regroupez-les autant que possible en une seule redirection vers l'URL canonique finale, et surveillez les boucles où deux règles se renvoient la requête en permanence.
Au minimum, envoyez Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, et une protection contre l'intégration via X-Frame-Options ou la directive frame-ancestors d'une CSP. HSTS impose le HTTPS, la CSP limite l'injection de scripts, nosniff empêche la confusion de type MIME, et la protection contre l'intégration bloque le clickjacking. Ensemble, ils couvrent les classes d'attaques côté navigateur les plus courantes avec des directives à définir une seule fois au niveau du serveur ou du CDN.
Une 301 est une redirection permanente et une 302 est temporaire. Une 301 indique aux navigateurs et aux moteurs de recherche que la ressource a été déplacée définitivement, de sorte qu'ils mettent à jour les favoris et transmettent les signaux de classement à la nouvelle URL. Une 302 signale que le déplacement est temporaire, et les clients continuent donc d'utiliser l'URL d'origine. Utilisez une 301 pour les redirections canoniques et vers HTTPS.