Il team SifG22 mi ha mostrato una falla nell'accesso agli account di Luxine

// rapporto di divulgazione responsabile · 11-10-2026
[1]  falla nel recupero password (F12) → account preso
[2]  service key di Supabase via console (F12)
[3]  chiave segreta ... luxine
// fine del metodo
------------------------------------------------
[fix] login / account / commenti ... DISATTIVATI
[fix] nuove API key secret .......... RIGENERANDO
[fix] rafforzamento RLS in SQL ...... IN CORSO
▍

La sicurezza digitale è uno di quegli aspetti dello sviluppo che possono passare inosservati finché qualcuno non dimostra che esiste un problema. Questa settimana l’ho vissuto da vicino e voglio raccontarlo con la massima trasparenza.

Per prima cosa, e più importante, un messaggio per chi ha un account su Luxine: ci dispiace per la preoccupazione che questo possa aver causato, ma per fortuna non è successo nulla di grave. Chi lo ha fatto è stato un team amico, il team SifG22, con un intento puramente preventivo, e non è stato divulgato né utilizzato alcun dato personale. Come misura precauzionale, mentre lo risolviamo abbiamo disattivato completamente l’accesso, gli account e i commenti. Torneranno disponibili non appena avremo finito di rafforzare la sicurezza.

Cosa è successo

Il team SifG22, con cui ho amicizia, è intervenuto su Luxine per dimostrarmi che esisteva un rischio da correggere prima che potesse trasformarsi in un problema più grande. Non è stato un attacco con cattive intenzioni: è stato un avviso.

Il metodo è stato semplice e, proprio per questo, rivelatore. Dalla console del browser (quella che si apre con F12) e tramite comandi, hanno sondato come si comportava il sito al suo interno. Da lì sono riusciti a cambiare la password di un account usando lo stesso pannello di login. Nient’altro: non è servito alcun trucco elaborato né l’accesso a server esterni, è bastato ciò che chiunque ha nel proprio browser.

Perché è stato possibile

La console del browser (F12) è un normale strumento di sviluppo: ogni visitatore ce l’ha. Il problema non è che esista, ma fidarsi che il browser si comporti bene. Se un’operazione sensibile —come cambiare una password— viene decisa lato client, qualcuno può manipolare quelle chiamate dalla console e aggirare i controlli.

La lezione è chiara: le operazioni critiche devono essere verificate sul server, mai solo nell’interfaccia. Non basta nascondere pulsanti o validare nel browser; il backend deve verificare, a ogni richiesta, che chi la effettua sia autorizzato a farlo. Questo è l’insegnamento principale di tutta questa esperienza.

Cosa ho disattivato mentre lo risolvo

Non ho voluto mascherare l’accaduto né lasciarlo correre. Ho preferito tagliare alla radice la superficie interessata e avvisare il pubblico. In questo momento:

• Accesso e account: disattivati. Le pagine di login e dell’account sono temporaneamente fuori servizio.
• Commenti e moderazione: disattivati, perché la scrittura dei commenti dipendeva dal sistema di account.
• Connessione a Supabase: scollegata sia dal frontend sia dal backend, così non si può leggere né scrivere nulla durante la revisione.
• Rotte di amministrazione: rimosse dal servizio pubblico.

C’è stata una fuga di informazioni?

Questa domanda va trattata con attenzione. Ciò che è stato dimostrato è che si poteva cambiare la password di un account dal client, ma questo non permette di per sé di concludere che siano stati estratti dati né che sia stata pubblicata informazione. Il team SifG22 ha amicizia con me e ha conservato le proprie schermate come prova, senza diffondere nulla.

Non voglio presentare come confermata una fuga che non è stata accertata. Per questo il passo successivo è rivedere i registri e stabilire cosa possa essere accaduto, prima di affermare qualsiasi cosa.

Cosa sto rafforzando

L’esperienza lascia un elenco chiaro di lavoro, già in corso:

• Verifica sul server: che il cambio di password e qualsiasi operazione sensibile vengano controllati sul backend, non nel browser.
• Flusso di accesso: rifare il login e il recupero della password affinché non possano essere manipolati dal client.
• Sessioni: rivedere i registri di autenticazione e chiudere qualsiasi sessione che potrebbe essere compromessa.
• Chiavi e dati: ruotare i segreti che servono, evitare di esporli nel frontend e rivedere le politiche di accesso in Supabase.

Cosa mi porto da questa esperienza

A volte, avere qualcuno di fiducia che segnala una falla è il modo migliore per scoprire che i tuoi sistemi hanno bisogno di più attenzione di quanto pensassi. Preferisco averlo saputo così, in modo preventivo, piuttosto che averlo scoperto tramite un incidente reale.

La sicurezza di un’applicazione non si dimostra affermando che è protetta, ma verificando che i suoi controlli funzionino quando conta davvero —e dal lato giusto, quello del server. Grazie per la comprensione mentre mettiamo tutto in ordine.