Nu a fost nevoie de un exploit sofisticat sau de o vulnerabilitate necunoscută. A fost nevoie doar ca cineva să lase o setare implicită neschimbată. Compania de cercetare în securitate cibernetică UpGuard a analizat aproximativ 300.000 de domenii care utilizau platforma cloud Supabase și a identificat peste 16.000 de baze de date configurate incorect și accesibile public pe internet, fără autentificare.
Principala problemă a fost lipsa sau configurarea greșită a politicilor de Row-Level Security (RLS) — mecanismul care stabilește cine poate vedea sau modifica anumite date dintr-un tabel — precum și utilizarea necorespunzătoare a cheilor publice de acces.
Consecința ? Baze de date care ar fi trebuit să fie private au rămas, din cauza unor erori de configurare, complet expuse pe internet.
Ce s-a găsit acolo nu e teoretic. În peste jumătate din cazuri, bazele de date expuse conțineau date cu caracter personal. Câteva exemple concrete, documentate de UpGuard:
- un serviciu de parcare (valet) din SUA — peste 100.000 de înregistrări de clienți, cu date de contact și numere de înmatriculare;
- un serviciu de imigrare din Canada — aproape 5.000 de conturi de utilizatori, dintre care 884 cu parole stocate în text simplu, necriptat;
- o platformă din India — peste 100.000 de mesaje private și date de plată;
- un serviciu de verificare prin cod OTP din Filipine — peste 2.000 de conturi și 100.000 de mesaje SMS;
- un consulat african — 25.000 de înregistrări de persoane, inclusiv adrese.
Un detaliu care merită reținut separat: potrivit UpGuard, 60% dintre bazele de date create recent pe platformă foloseau dezvoltare asistată de AI — iar o parte semnificativă a configurărilor greșite pare să vină din faptul că agenții AI de programare generează infrastructura, iar oamenii din spatele proiectului nu mai verifică (sau nu mai știu) exact ce a fost expus public.
De ce contează asta pentru orice companie, nu doar pentru cele din exemple
Povestea nu e despre Supabase ca platformă — e despre un tipar care se repetă în cloud, indiferent de furnizor: setările implicite sunt gândite pentru viteză de dezvoltare, nu pentru securitate maximă, iar responsabilitatea de a le verifica rămâne, în cele din urmă, a echipei care implementează. Cu cât mai mult din cod și din infrastructură e generat automat — inclusiv cu ajutorul AI — cu atât mai ușor devine să pierzi din vedere ce anume ai lăsat accesibil din exterior.
Practic, nu e nevoie de un audit complex ca să pornești: verificarea politicilor de acces la nivel de rând, a cheilor publice folosite și a permisiunilor implicite pe orice bază de date nouă, cloud sau on-premise, rămâne primul pas simplu, dar frecvent omis.