Il caso .bank.in riporta al centro un tema spesso sottovalutato: un dominio pensato come segnale di fiducia funziona solo se il registro che lo governa è altrettanto affidabile. Secondo un report pubblicato da CashlessConsumer e ripreso da The Register, il portale di registrazione gestito dall’Institute for Development and Research in Banking Technology, o IDRBT, avrebbe esposto dati degli amministratori dei domini bancari indiani tramite oltre 33 endpoint API non autenticati.
Il namespace .bank.in è stato introdotto in India come misura anti-phishing: l’obiettivo è spostare i siti delle banche locali su un suffisso riconoscibile, riservato e controllato, così da rendere più difficile la creazione di domini ingannevoli. Proprio per questo la notizia è rilevante anche fuori dall’India. Quando un TLD o sottodominio regolato viene presentato come garanzia di autenticità, la sicurezza del back-end diventa parte del prodotto.
Leggi anche: DNS abuse: perché i numeri delle blocklist vanno letti con prudenza
Che cosa sarebbe stato esposto
Il report attribuito al ricercatore Srikanth L parla di dati relativi a migliaia di persone incaricate di gestire domini bancari: hash bcrypt delle password, email, numeri di telefono, IP di login e fingerprint dei dispositivi. La cifra citata dalla fonte è 5.576 profili collegati alla gestione dei domini, con una esposizione rimasta aperta per circa 13 mesi.
Le password non sarebbero state conservate in chiaro, e questo riduce una parte del rischio. Ma non elimina il problema. Email, telefono, IP e impronte dispositivo sono informazioni utili per campagne mirate contro amministratori ad alto valore. In un contesto bancario, l’obiettivo non è necessariamente rubare subito una password: può bastare costruire un attacco credibile verso chi gestisce DNS, certificati, deleghe e modifiche operative.
Secondo la ricostruzione pubblica, la vulnerabilità è stata segnalata a CERT-In l’8 giugno 2026, corretta da IDRBT il 25 giugno e considerata risolta il 26 giugno. Al momento delle prime pubblicazioni, The Register riportava l’assenza di commenti pubblici da IDRBT, Reserve Bank of India e governo indiano.
Perché non è una fuga dati qualunque
Una fuga di dati personali è grave in sé. Qui, però, il punto è più specifico: riguarda persone che amministrano un namespace creato per aumentare la fiducia nel banking online. Il dominio non è solo un’etichetta; è un pezzo di infrastruttura che indirizza utenti, servizi, certificati, email e reputazione.
Se un aggressore riuscisse a colpire gli account di amministrazione o a sfruttare le informazioni esposte per impersonare un referente legittimo, il danno potenziale andrebbe oltre la privacy. Potrebbe toccare il controllo dei record, la gestione dei nomi, la configurazione di servizi collegati e la percezione pubblica del suffisso. È il motivo per cui i registry, soprattutto quelli legati a settori regolati, devono essere trattati come infrastrutture critiche.
Leggi anche: Il caso .pk mostra perché la governance dei ccTLD è un tema di sicurezza
Il paradosso dei namespace protetti
I namespace riservati, verificati o settoriali hanno una promessa forte: ridurre la confusione per l’utente finale. Nel settore bancario questa promessa è particolarmente utile, perché phishing, typo domain, domini lookalike e brand abuse sfruttano proprio la fretta o la scarsa familiarità dell’utente con l’indirizzo corretto.
Ma più un suffisso diventa un bollino di fiducia, più il suo processo di emissione diventa appetibile. Gli attaccanti non devono più convincere l’utente che un dominio falso sia legittimo se riescono a puntare alla filiera che rende legittimo il dominio vero. Questo non significa che modelli come .bank.in siano sbagliati; significa che devono avere standard di sicurezza proporzionati al ruolo che promettono di svolgere.
La lezione vale anche per nuovi gTLD, ccTLD, registry verticali e iniziative pubbliche. Un registro non può limitarsi a controllare l’eleggibilità in fase di registrazione. Deve proteggere il portale, gli account, le API, i log, i workflow di approvazione, le procedure di incident response e le comunicazioni con i registranti.
DNSSEC, DMARC e igiene operativa
Il report segnala anche aspetti di igiene tecnica collegati ai domini censiti, inclusa una presenza non uniforme di DNSSEC e DMARC. Sono elementi diversi dalla falla API, ma fanno parte dello stesso discorso: la fiducia non nasce da una sola regola, bensì da una catena di controlli coerenti.
DNSSEC aiuta a proteggere l’integrità delle risposte DNS; DMARC contribuisce a ridurre l’abuso email del dominio; audit indipendenti e vulnerability disclosure program rendono più credibile la sicurezza applicativa del portale. Se uno di questi livelli manca, il namespace resta utile, ma meno solido di quanto la sua comunicazione pubblica possa far pensare.
Leggi anche: Nuovi gTLD 2026: perché la scelta del RSP pesa quanto la stringa
La lettura Webinvest
Il caso .bank.in va letto come un avvertimento per tutto il mercato dei domini. I suffissi “di fiducia” possono essere strumenti efficaci contro frodi e phishing, ma non trasferiscono magicamente fiducia all’utente: la guadagnano ogni giorno attraverso sicurezza, trasparenza e governance.
Per registry e registrar, il messaggio operativo è netto. Le API non sono dettagli interni, gli account amministrativi non sono semplici profili utente e i processi di registrazione non sono back office invisibile. Sono parte dell’infrastruttura DNS. Se un namespace promette maggiore sicurezza, il livello minimo accettabile per portali, audit, autenticazione e disclosure deve essere più alto della media.
Per aziende e istituzioni che valutano domini settoriali, dotBrand o namespace regolati, la domanda non deve essere solo “chi può registrare?” ma anche “chi protegge il sistema che permette di registrare?”. Nel mercato dei domini, la fiducia non sta solo a destra del punto: sta in tutta la catena che rende quel punto credibile.
Fonti: report CashlessConsumer su .bank.in, The Register e Webhosting.Today.
← Tutte le news