En quelques secondes et sans rien installer, Web-Check vous permet de savoir ce qui se cache derrière un site web : son hébergeur, ses enregistrements DNS, ses certificats TLS, ses en-têtes de sécurité ou encore les technologies qu’il utilise. Voilà une boîte à outils précieuse pour qui s’intéresse à la reconnaissance, à la veille ou à l’audit technique d’un site web. Découvrons cet outil ensemble !
On peut imaginer différents cas d’usage qui peuvent nous amener à analyser un domaine avec cet outil. Par exemple, vous avez reçu un lien douteux par e-mail et vous voulez en savoir plus sur le domaine avant de cliquer. Un second exemple ? En voici un : vous souhaitez vérifier la surface d’exposition de votre propre site. Plutôt que d’enchaîner une dizaine de services en ligne différents, Web-Check centralise toutes ces vérifications sur une seule page.
Comme le mentionne Web-Check, vous allez passer votre site web au rayon X.
Dans cet article, je vous propose de découvrir Web-Check : ce qu’il est, ce qu’il sait analyser, comment l’utiliser via son instance publique, puis comment l’auto-héberger avec Docker pour vos propres besoins.
Qu’est-ce que Web-Check ?
Web-Check est un outil OSINT qui collecte et présente, sur un tableau de bord unique, un grand nombre d’informations techniques publiques sur un site web ou un domaine. À partir d’une simple URL, il interroge le DNS, le certificat TLS, les en-têtes HTTP, les bases Whois, les listes de réputation et d’autres sources, puis affiche le résultat sous forme de fiches lisibles. Il existe de nombreux outils pour analyser en détail un site web, mais l’avantage de Web-Check, c’est le côté agrégateur : vous avez beaucoup d’informations regroupées sur une même page. Vous pourrez ensuite poursuivre l’analyse en utilisant un outil plus spécifique au périmètre à approfondir.
Qu’est-ce que l’OSINT ? L’OSINT (Open Source Intelligence) désigne le renseignement obtenu à partir de sources d’information ouvertes et accessibles à tous. Pour approfondir cette discipline, consultez mon article Qu’est-ce que l’OSINT ?.
Web-Check est développé par Alicia Sykes (alias Lissy93 sur GitHub), une développeuse connue pour plusieurs projets open source populaires. Ce projet est open source, publié sous licence MIT et totalement gratuit : vous pouvez utiliser l’instance publique ou auto-héberger la vôtre via Docker.
Voici les deux ressources officielles du projet :
Que peut analyser Web-Check ?
La force de Web-Check, c’est son périmètre : plus d’une trentaine de modules d’analyse sont lancés à la volée sur le site web à analyser. Pour s’y retrouver, j’ai regroupé les principaux contrôles par thématique. Une fois l’analyse effectuée, un rapport s’affiche avec des résultats par module et des conseils sur la partie haute de la page. Cela signifie que Web Check peut aussi vous aider à améliorer la sécurité de votre site web et de votre domaine.
Ci-dessous, plus d’informations à propos de ce que vous pourrez trouver dans ce rapport, avec un exemple.
Identité du domaine et DNS
Cette famille couvre le WHOIS (date de création, registrar, date d’expiration, statut DNSSEC déclaré), les enregistrements DNS de type A, les serveurs de noms, les enregistrements TXT, la configuration du serveur DNS faisant autorité, et la vérification effective de DNSSEC via la présence des enregistrements DNSKEY, DS et RRSIG.
Web-Check vérifie également la configuration de messagerie du domaine, ce qui recoupe directement les enregistrements que vous mettez en place lorsque vous travaillez la sécurité de la messagerie avec SPF, DKIM et DMARC.
Trois cartes distinctes traitent de TLS : le certificat lui-même (émetteur, sujet, dates de validité, empreinte, usages étendus de clé), la connexion TLS négociée, et un audit de sécurité TLS (avec le score SSL Labs). Cette partie s’appuie d’ailleurs sur l’API publique de SSL Labs. S’y ajoute la vérification de HSTS, qui indique si le site force le navigateur à n’utiliser que HTTPS.
On trouve ici le scan de ports, le traceroute, la géolocalisation du serveur, les noms d’hôtes associés à l’adresse IP, la détection de pare-feu applicatif (WAF) et l’énumération de sous-domaines. D’ailleurs, le scan de ports est un point particulier avec cet outil : ce n’est plus du scan passif, il va vraiment scanner la cible pour tester les ports (une petite trentaine). Autrement dit, il teste les ports les plus fréquemment utilisés sur les services Web : 80, 443, 8080 et même le 3306 (au cas où vous auriez une instance MySQL exposée sur le Web).
Sécurité applicative et réputation
Cette famille de tests regroupe l’analyse des en-têtes HTTP de sécurité, les cookies déposés, la présence d’un fichier security.txt (pour signaler les problèmes de sécurité), les règles de robots.txt (pour l’indexation), la vérification du domaine face à douze résolveurs DNS avec filtrage (notamment AdGuard, CleanBrowsing Family, ou encore OpenDNS Family), et l’interrogation de plusieurs bases de menaces.
Contexte et métadonnées
Enfin, Web-Check récupère le classement mondial du domaine, la stack technique détectée (Apache2, Nginx… WordPress… Plugins et thèmes WordPress, etc.), les balises relatives aux réseaux sociaux, les pages liées, le sitemap, les redirections, l’empreinte carbone estimée et une capture d’écran de la page d’accueil.
Selon le site web analysé, il y aura plus ou moins d’informations dans le rapport généré. Ci-dessous, un test effectué sur l’adresse expired.badssl.com, où il y a volontairement des défauts, dont un certificat TLS expiré. Sur des sites web, le reporting est beaucoup plus complet, mais je vous laisserai essayer sur votre blog ou le site web de votre boîte. Vous remarquerez également qu’il y a des liens vers d’autres plateformes : DNS Dumpster, Shodan, Wayback Machine, etc…. avec des liens préconfigurés pour poursuivre l’analyse du domaine sur des outils connexes.
Dans le rapport ci-dessus, l’encart Advisory, c’est la première chose qui saute aux yeux. Un moteur d’analyse applique des règles aux résultats bruts afin de vous suggérer des points à corriger, tout en les classant par gravité.
Sur notre exemple, l’encart remonte :
Critical (2) : le certificat SSL est invalide et il a expiré (et on sait depuis quand).
Warnings (1) : « DNSSEC not enabled », assorti d’une explication sur le risque d’usurpation et d’empoisonnement de cache.
Passes (3) : enregistrement du domaine valide, aucune correspondance dans les flux de menaces, absence de ce domaine dans les listes de blocage DNS testées.
Même si vous pouvez consulter l’ensemble du rapport, il y a cette partie Advisory qui facilite l’analyse.
Tester Web-Check en ligne
Le moyen le plus rapide de découvrir l’outil consiste à utiliser l’instance publique accessible sur web-check.xyz. Aucune installation ni inscription n’est requise : vous saisissez un nom de domaine ou une URL, vous lancez l’analyse, et le tableau de bord se remplit progressivement au fur et à mesure que les différents modules retournent leurs résultats.
C’est idéal pour une consultation ponctuelle. En revanche, pour un usage régulier et l’utilisation dans votre boîte à outils, je vous recommande d’auto-héberger cet outil à l’aide de Docker.
Héberger Web-Check soi-même avec Docker
Auto-héberger Web-Check présente plusieurs avantages : vous n’êtes plus soumis aux limites de l’instance publique, vous gardez la maîtrise de vos requêtes (utile lorsque vous analysez des sites sensibles), et vous pouvez renseigner vos propres clés d’API pour débloquer les contrôles avancés.
Déploiement rapide avec Docker
Pour une simple prise en main, l’image officielle se lance en une seule commande. Le conteneur expose son interface sur le port 3000 :
docker run -p 3000:3000 lissy93/web-check
Une fois le conteneur démarré, l’interface est accessible à l’adresse http://localhost:3000 (ou http://:3000). L’image officielle est publiée sur le Docker Hub (lissy93/web-check) et sur le registre GitHub (GHCR).
Déploiement avec Docker Compose
Pour intégrer Web Check à votre boite à outils, il est préférable d’utiliser un Docker Compose et un fichier .env, afin de centraliser la configuration. Comme vous le savez, j’ai l’habitude de stocker mes stacks dans un sous-dossier dédié, soit ici : /opt/docker-compose/web-check.
Créez l’arborescence du projet :
sudo mkdir -p /opt/docker-compose/web-check
cd /opt/docker-compose/web-check
Créez le fichier docker-compose.yml avec cette configuration :
services:
web-check:
image: lissy93/web-check:latest
container_name: web-check
env_file:
– .env
ports:
– “3000:3000”
security_opt:
– no-new-privileges:true
restart: unless-stopped
Créez ensuite le fichier .env à côté du Compose, ce qui évite d’éditer le docker-compose.yml à chaque ajustement. Il y a plusieurs options prises en charge par Web Check. Ici, je vous indique celles qui permettent de préciser des clés d’API :
GOOGLE_CLOUD_API_KEY=
SHODAN_API_KEY=
CLOUDMERSIVE_API_KEY=
TRANCO_USERNAME=
TRANCO_API_KEY=
CERTSPOTTER_TOKEN=
Les données collectées via ces services tiers vont alimenter certaines cartes de Web Check. A ce sujet, voici quelques précisions :
Web-Check fonctionne sans aucune clé API, mais certaines cartes restent alors vides. Voici les variables réellement lues par le code :
VariableServiceGOOGLE_CLOUD_API_KEYPageSpeed Insights et Safe BrowsingSHODAN_API_KEYShodanTRANCO_USERNAME et TRANCO_API_KEYTrancoCLOUDMERSIVE_API_KEYCloudmersiveCERTSPOTTER_TOKENcertSpotter
Quand c’est tout bon, enregistre les fichiers.
Démarrez ensuite la stack Docker Compose :
# Se placer dans le dossier du projet, puis démarrer en arrière-plan
cd /opt/docker-compose/web-check
docker compose up -d
# Vérifier l’état du conteneur
docker compose ps
# Suivre les journaux en cas de besoin
docker compose logs -f
Tant que l’outil reste sur votre réseau local, une exposition directe sur le port 3000 suffit. Mais si vous souhaitez y accéder à distance, ne publiez jamais le conteneur tel quel sur Internet : placez-le derrière un reverse proxy qui se charge du HTTPS et, idéalement, d’une authentification. Pour ma part, j’utilise Traefik, vous pouvez suivre mon tutoriel Débuter avec Traefik : un reverse proxy moderne pour vos services Web Docker.
Utiliser Web-Check comme une API
Au-delà d’utiliser Web-Check depuis l’interface web, vous pouvez aussi interroger son API native depuis la ligne de commande. Chaque vérification effectuée par l’outil correspond à un point de terminaison HTTP indépendant. Ci-dessous, quelques exemples.
Récupérer les informations de certificat SSL au format JSON
curl “http://localhost:3000/api/ssl?url=it-connect.fr”
Vérifier l’état de DNSSEC
curl “http://localhost:3000/api/dnssec?url=it-connect.fr”
Lister les sous-domaines connus
curl “http://localhost:3000/api/subdomains?url=it-connect.fr”
Afficher les informations WHOIS
curl “http://localhost:3000/api/whois?url=it-connect.fr”
{“domain”:”it-connect.fr”,”registrar”:”IONOS SE”,”registrarUrl”:”https://ionos.com”,”created”:”2013-06-13T19:58:12.000Z”,”updated”:”2024-04-13T08:58:34.801Z”,”expires”:”2029-06-13T19:58:12.000Z”,”nameservers”:[“dingo.ezoicns.com”,”hyena.ezoicns.com”,”tetra.ezoicns.com”,”zorse.ezoicns.com”],”status”:[“clientTransferProhibited”]}% http://localhost:3000/
Les points de terminaison portent le nom de la vérification : ssl, dns, dnssec, whois, headers, http-security, hsts, ports, subdomains, mail-config, tech-stack, threats, block-lists, archives, redirects, robots-txt, security-txt, social-tags, sitemap, screenshot, et ainsi de suite.
Il est également possible de lancer le conteneur en mode API pure, sans interface graphique, en positionnant DISABLE_GUI=true. C’est le mode adapté si vous branchez Web-Check sur un système de supervision ou sur un script.
Limites et cadre d’utilisation
Web-Check n’est pas un scanner de vulnérabilités. Il ne teste aucune injection, ne détecte aucune CVE applicative et ne remplace ni un audit ni un test d’intrusion. Il cartographie une surface, il ne l’attaque pas.
La détection reste largement déclarative. WAF, stack technique, présence d’un CDN : tout repose sur ce que le serveur veut bien annoncer dans ses en-têtes. Un serveur bien configuré renverra volontairement peu d’informations, et Web-Check affichera alors des cartes vides ou incomplètes. Ce n’est pas un défaut de l’outil, c’est même le signe d’une bonne hygiène côté cible. Si le serveur est protégé par un système comme Cloudflare, il est aussi fort probable que les résultats ne reflètent pas la configuration réelle du serveur.
Le scan de ports est un module actif. C’est le point à retenir sur le plan juridique. Limitez vos analyses à vos propres domaines, à ceux pour lesquels vous disposez d’une autorisation ou vers des cibles destinées aux tests.
Je trouve que passer son propre domaine à Web-Check est un bon révélateur, cela permet un audit rapide qui amène ensuite à approfondir certains points.
Conclusion
Web-Check est un excellent outil pour ce qu’il prétend être : un agrégateur de reconnaissance, rapide, lisible et entièrement open source. À cela s’ajoutent des bonus comme la section Advisory constituée de conseils applicables et la présence d’un API pour interroger l’outil depuis des scripts ou des outils tiers. Pour une première passe de reconnaissance, pour un contrôle périodique de votre propre surface exposée, ou pour donner à un client une vision immédiate de ce qu’un attaquant peut apprendre de lui, il rend un vrai service !
Le fait que l’on puisse auto-héberger cet outil et accéder à son code source, c’est aussi des points forts qui me poussent à l’utiliser. Pour aller plus loin, consultez la documentation et le dépôt GitHub du projet pour suivre les évolutions.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.