Websites herunterladen, die Kong nutzen

Über Kong

Ein API-Gateway ist darauf ausgelegt, nicht aufzufallen. Kong steht zwischen den Clients und den Diensten dahinter, terminiert Anfragen, prüft Zugangsdaten, zählt Aufrufe und leitet weiter, was diese Prüfungen übersteht. Eine sorgfältig konfigurierte Installation hinterlässt in einer Antwort kaum Spuren von sich selbst. Eine Liste von Domains, auf denen das Gateway überhaupt sichtbar ist, ist daher eine Liste von Installationen, die sich entweder bewusst nicht verstecken oder nie entsprechend eingestellt wurden.

Wo man hinschaut, zählt ebenso viel wie die Erkennung selbst. Gateways liegen meist auf einer api-Subdomain oder einem internen Hostnamen, während ein Datensatz zu Webtechnologien betrachtet, was eine öffentliche Website ausliefert. Ein Treffer bedeutet hier in der Regel, dass das Gateway der öffentlichen Website selbst vorgeschaltet ist, was ein anderes und selteneres Einsatzmuster ist als das übliche. Ein solcher Treffer deutet meist auf ein Team hin, das seine gesamte Edge-Infrastruktur hinter eine einzige Komponente der Kategorie Reverse proxies gestellt hat, statt für die Website einen separaten Proxy einzusetzen.

Wo das Gateway sichtbar ist, sagt das etwas über die Organisation aus, nicht über die Optik. Ein Team, das seinen Diensten Kong vorschaltet, hat Schnittstellen, die es zu steuern lohnt, mehr als ein Backend und jemanden, zu dessen Aufgaben Rate Limits, Authentifizierung und Traffic-Richtlinien gehören. Das Gateway ist in Lua geschrieben, setzt auf einem etablierten Proxy-Kern auf und wird von Plattformteams ausgewählt, nicht von demjenigen, der das Content-Management-System ausgesucht hat. In der Regel tritt es gemeinsam mit Container-Orchestrierung, einer Service-Registry und einer Deployment-Pipeline auf.

Die Lizenz Apache 2.0 erklärt einen Großteil der Streuung. Der Anbieter Kong Inc. veröffentlicht eine Open-Core-Variante, die jeder betreiben kann, ohne je mit einem Vertriebsmitarbeiter zu sprechen, daneben eine kommerzielle Edition und einen Managed Service, sodass die Installationen von einem einzelnen Container vor einem Hobbyprojekt bis zur regulierten Konzerninfrastruktur reichen. Das Gateway erschien erstmals im Jahr 2015, genau zu der Zeit, als Microservice-Architekturen zum Standard wurden, und ein großer Teil dessen, was wir erkennen, gehört zu Systemen, die in dieser Phase entworfen wurden.

An den Versionsdaten wird das Bild für alle unbequem, die für eine Flotte von Installationen verantwortlich sind. Wir erfassen in freier Wildbahn 72 verschiedene Versionen, wobei Version 1.4.1 häufiger vorkommt als jede andere, und ein selbst gehostetes Gateway aktualisiert sich nicht von allein. Alte Builds liefern weiter Traffic aus, weil sie funktionieren, weil die an sie gebundenen Plugins nie erneut getestet wurden oder weil der Entwickler, der sie ausgerollt hat, inzwischen weitergezogen ist. Für die Sicherheitsforschung ist die Verteilung über die Domains nützlicher als jede Gesamtzahl, denn ein Sicherheitshinweis betrifft einen Bereich von Releases und nicht einen Produktnamen.

Stand Oktober 2026 sehen wir Kong auf 5.901 Websites, und die Zahl sollte als Untergrenze gelesen werden. Gateways hinter einem Content Delivery Network, das Header umschreibt, oder solche, die identifizierende Antworten gezielt entfernen, tauchen schlicht nie auf. Was ein vollständiger Auszug über eine Einzelabfrage hinaus bietet, ist die Struktur des Bestands: welche Branchen sich auf das Gateway als Standard festgelegt haben, welche Infrastrukturen es neben einem konkurrierenden Proxy betreiben und welche Domains noch auf Releases laufen, die ein bestimmter Sicherheitshinweis betrifft. Teams bei Anbietern nutzen solche Listen für Verdrängungsanalysen, Sicherheitsteams für die Kartierung von Angriffsflächen und Analysten, um zu beurteilen, ob aus einem Open-Core-Modell tatsächlich bezahlte Infrastruktur geworden ist.