Télécharger les sites web qui utilisent Kong

À propos de Kong

Une passerelle d’API est faite pour passer inaperçue. Kong se place entre les clients et les services qui se trouvent derrière eux, termine les requêtes, vérifie les identifiants, compte les appels et transmet ce qui survit, et un déploiement soigneusement configuré laisse très peu de traces de lui-même dans une réponse. Une liste de domaines où la passerelle est visible tout court, c’est donc une liste de déploiements qui ont choisi de ne pas se cacher ou que personne n’a jamais réglés pour cela.

La surface d’observation compte autant que la détection. Les passerelles se trouvent le plus souvent sur un sous-domaine api ou sur un nom d’hôte interne, alors qu’un dataset de technologies web regarde ce que sert un site public. Une correspondance ici signifie en général que la passerelle se place devant la propriété web publique elle-même, ce qui est un schéma de déploiement différent et moins courant que l’ordinaire, et cela tend à désigner une équipe qui a fait passer tout son trafic d’entrée par un seul composant de la catégorie Reverse proxies plutôt que par un proxy distinct pour le site web.

Là où la passerelle est visible, l’implication est organisationnelle plutôt que cosmétique. Une équipe qui place Kong devant ses services a des interfaces qui méritent d’être gouvernées, plus d’un backend et quelqu’un dont la fiche de poste comprend les limites de débit, l’authentification et la politique de trafic. Écrite en Lua par-dessus un cœur de proxy éprouvé, la passerelle est choisie par des ingénieurs de plateforme et non par celui qui a retenu le système de gestion de contenu, et elle s’accompagne le plus souvent d’une orchestration de conteneurs, d’un registre de services et d’une chaîne de déploiement.

La licence Apache 2.0 explique une grande partie de cet éventail. Kong Inc. publie un noyau ouvert que n’importe qui peut faire tourner sans jamais parler à un commercial, aux côtés d’une édition commerciale et d’un service infogéré, de sorte que les déploiements vont d’un conteneur unique devant un projet de loisir à un parc d’entreprise réglementé. Sortie pour la première fois en 2015, la passerelle est arrivée au moment précis où les architectures en microservices devenaient la norme par défaut, et une large part de ce que nous détectons appartient à des systèmes conçus à cette période.

C’est dans les données de version que le tableau devient inconfortable pour quiconque a la charge d’un parc. Nous enregistrons 72 versions distinctes en circulation, 1.4.1 revenant plus souvent que toute autre, et une passerelle auto-hébergée ne se met pas à jour toute seule. Les anciennes compilations continuent de servir du trafic parce qu’elles fonctionnent, parce que les extensions qui leur sont épinglées n’ont jamais été retestées, ou parce que l’ingénieur qui les a déployées est parti ailleurs. Pour la recherche en sécurité, la répartition entre les domaines est plus utile que n’importe quel total, puisqu’un bulletin d’alerte couvre une plage de versions et non un nom de produit.

En octobre 2026 nous voyons Kong sur 5 901 sites, et ce chiffre doit se lire comme un plancher. Les passerelles placées derrière un réseau de diffusion de contenu qui réécrit les en-têtes, ou configurées pour retirer les réponses identifiantes, n’apparaissent purement et simplement jamais. Ce qu’un export complet apporte au-delà d’une requête unique, c’est la forme de la population : quels secteurs se sont standardisés sur la passerelle, quels parcs la font tourner à côté d’un proxy concurrent, et quels domaines reposent encore sur des versions couvertes par un bulletin donné. Les équipes des fournisseurs utilisent des listes de ce genre pour repérer les comptes à prendre à la concurrence, les équipes de sécurité pour cartographier l’exposition, et les analystes pour juger si un noyau ouvert s’est réellement converti en infrastructure payante.