Scaricare i siti web che utilizzano Kong

Informazioni su Kong

Un API gateway è costruito per passare inosservato. Kong si colloca tra i client e i servizi retrostanti: termina le richieste, verifica le credenziali, conta le chiamate e inoltra tutto ciò che supera i controlli, e un’installazione configurata con cura lascia ben poche tracce di sé in una risposta. Un elenco dei domini in cui il gateway risulta comunque visibile è quindi un elenco di installazioni che hanno scelto di non nascondersi oppure che non sono mai state configurate per farlo.

La superficie osservata conta quanto il rilevamento. Di solito i gateway si trovano su un sottodominio api o su un hostname interno, mentre un dataset di tecnologie web esamina ciò che un sito pubblico distribuisce ai visitatori. Qui una corrispondenza in genere significa che il gateway si colloca davanti al sito pubblico stesso, il che costituisce uno schema di installazione diverso e meno comune di quello ordinario, e tende a indicare un team che ha messo l’intero perimetro dietro un unico componente della categoria Reverse proxies anziché affiancare al sito web un proxy separato.

Dove il gateway è visibile, l’implicazione è organizzativa più che estetica. Un team che mette Kong davanti ai propri servizi ha interfacce che vale la pena governare, più di un backend e qualcuno nel cui mansionario rientrano limiti di frequenza delle chiamate, autenticazione e policy del traffico. Scritto in Lua sopra un nucleo proxy consolidato, il gateway viene scelto dagli ingegneri di piattaforma e non da chi ha scelto il sistema di gestione dei contenuti, e di solito arriva insieme all’orchestrazione dei container, a un registro dei servizi e a una pipeline di deployment.

La licenza Apache 2.0 spiega gran parte dell’eterogeneità delle installazioni. Kong Inc. pubblica una versione open core che chiunque può far girare senza mai parlare con un commerciale, insieme a un’edizione commerciale e a un servizio gestito, per cui le installazioni vanno da un singolo container davanti a un progetto amatoriale fino al parco di un’impresa che opera in un settore regolamentato. Rilasciato per la prima volta nel 2015, il gateway è arrivato proprio quando le architetture a microservizi stavano diventando la norma, e buona parte di ciò che rileviamo appartiene a sistemi progettati in quel periodo.

È nei dati di versione che il quadro diventa scomodo per chi è responsabile di una flotta di installazioni. Registriamo 102 versioni distinte in circolazione, con 1.4.1 come versione più ricorrente, e un gateway installato in proprio non si aggiorna da solo. Le build vecchie continuano a servire traffico perché funzionano, perché i plugin legati a quelle versioni non sono mai stati testati di nuovo, oppure perché l’ingegnere che le aveva installate è passato ad altro. Per la ricerca sulla sicurezza la distribuzione tra i domini è più utile di qualsiasi totale, perché un bollettino di sicurezza riguarda un intervallo di release e non il nome di un prodotto.

A ottobre 2026 vediamo Kong su 18.609 siti, e il dato va letto come una stima per difetto. I gateway che si trovano dietro una rete di distribuzione dei contenuti che riscrive le intestazioni, o che sono configurati per eliminare le risposte identificative, semplicemente non emergono mai. Rispetto a una verifica puntuale, un’estrazione completa offre la forma della popolazione: quali settori si sono standardizzati sul gateway, quali parchi lo affiancano a un proxy concorrente e quali domini sono ancora fermi su release coperte da un determinato bollettino. I team dei fornitori usano elenchi come questo per le ricerche finalizzate a sottrarre clienti ai concorrenti, i team di sicurezza per mappare l’esposizione e gli analisti per valutare se un modello open core si sia davvero tradotto in infrastruttura a pagamento.