Conform cercetării UpGuard, partajate exclusiv cu TechCrunch, au fost identificate aproximativ 16.000 de baze de date pe care un grad anumit de date personale era expus public în timp ce erau găzduite de Supabase. Platforma, care a atins o evaluare de 10 miliarde de dolari în începutul acestui an, s-a transformat în spatele tehnic preferat al unei noi generații de dezvoltatori care construiesc aplicații la viteză luminoasă, adesea copiind și lipind cod generat de modele de limbaj largi (LLM-uri) fără a verifica configurările de securitate de bază.
Supabase, o alternativă open-source la Firebase, oferă o bază de date PostgreSQL, autentificare, API-uri instantanee și stocare de fișiere, totul împachetat într-o interfață ușor de folosit. Această ușurință, combinată cu promisiunea de a "lansa în minute", a atras o mulțime de developeri juniori, fondatori non-tehnici și entuziaști AI care construiesc produse în weekenduri — ceea ce industriele numește acum "vibe coding". Dar ușurința de a porni un proiect nu înseamnă că acesta este securizat implicit.
Ce a găsit UpGuard nu sunt vulnerabilități în codul Supabase, ci configurații greșite făcute de clienți. Mulți dezvoltatori dezactivează, intenționat sau din neștiință, Row Level Security (RLS) — mecanismul nativ al PostgreSQL care restricționează accesul la rânduri bazat pe politici — sau lasă cheile API (anon key și service_role key) expuse în codul frontend, accesibile oricărui inspector de browser. Alții configurează bucket-urile de stocare ca fiind publice, permițând descărcarea fișierelor fără autentificare.
Datele expuse sunt de o varietate și sensibilitate îngrijorătoare. Cercetătorii au descoperit: conversații private între utilizatori și sex workers pe un site indian de streaming pentru adulți; mii de numere de înmatriculare ale unui serviciu de valet din Statele Unite; informații de contact ale persoanelor care foloseau un serviciu de imigrare și relocare; date apartinând unui consulat al unui guvern african situat în Franța; și, poate cel mai înfricoșător, o bază de date folosită de o "fermă de SIM-uri virtuale" pentru a intercepta mesaje text cu coduri de acces unice (OTP), o infrastructură tipică pentru atacuri de phishing și fraudă la scară largă.
Deși majoritatea seturilor de date identificate se află în Statele Unite, UpGuard subliniază că este o problemă globală. Platforma Supabase este folosită de dezvoltatori din întreaga lume, iar lipsa de standarde de securitate obligatorii la nivel de platformă înseamnă că oricine, indiferent de locație sau expertiză, poate expune date critice cu câteva click-uri greșite.
Aceasta nu este prima dată când Supabase se află sub lupele cercetătorilor de securitate. Studii anterioare au evidențiat baze de date expuse apartinând startup-urilor din portofoliul Y Combinator, aplicațiilor populare și a altor proiecte de înalt profil. În răspuns, Supabase a implementat în timp diverse îmbunătățiri: avertismente mai vizibile în dashboard când RLS este dezactivat, scanări automate pentru configurații insecurizate, și notificări email către clienți afectați când sunt descoperite probleme.
Când a fost contactat pentru comentarii, Directorul de Securitate a Informației (CISO) al Supabase, Bil Harmer, a declarat că, deși compania nu a văzut încă raportul UpGuard, proiectele sunt "securizate implicit" (secure by default). Harmer a descris securitatea ca o "responsabilitate partajată" între platformă și clienți: "Oferim configurații securizate implicit și instrumente, iar clienții controlează cum sunt configurate propriile proiecte", a spus el, adăugând că compania notifică clienții afectați când sunt descoperite probleme de securitate. "Securitatea la Supabase nu se termină niciodată. Ne pasă profund să o facem corect, și vom continua să o facem mai ușoară pentru fiecare dezvoltator să lanceze produse securizate", a concluzionat Harmer.
Această poziție — "secure by default, dar responsabilitatea e a ta" — este standardă în industrie (modelul responsabilității partajate AWS/Azure/GCP), dar criticii argumentează că, în contextul actual al vibe coding-ului, este insuficientă. Când un fondator non-tehnic folosește Cursor sau Copilot să genereze o aplicație completă în două ore, nu are cunoștințele pentru a înțelege ce este RLS, de ce cheia `service_role` nu trebuie să ajungă niciodată în browser, sau cum să configureze politici de acces corecte. Codul generat de AI funcționează adesea "din prima" dar ignoră securitatea, pentru că modelele sunt antrenate pe tutoriale care priorizează funcționalitatea, nu hardening-ul.
Greg Pollock, cercetătorul de securitate de la UpGuard care a condus investigația, a subliniat importanța cercetării pentru creșterea conștientizării asupra expunerilor de date. "Multe dintre aceste expuneri nu sunt rezultatul unor atacuri sofisticate, ci al unor greșeli de configurare triviale pe care oricine ar fi putut să le evite cu cunoștințe de bază", a declarat Pollock. "Problema este că ecosistemul actual încurajează viteza la détrimentul securității, și platformele trebuie să facă mai mult decât să pună avertismente în documentație."
Unele voci din comunitate propun soluții mai aggressive: forțarea activării RLS la crearea tabelelor (cu opțiune de dezactivare explicită, nu implicită), scanarea automată a cheilor expuse în repo-urile GitHub publice, blocarea deploy-ului dacă sunt detectate configurații critice insecurizate, sau chiar izolarea proiectelor noi într-un mod "sandbox" până la trecerea unui audit de securitate automat. Supabase a început să experimenteze cu unele dintre aceste idei, dar adoptarea largă și forțarea lor rămâne o problemă deschisă.
Fenomenul nu este unic Supabase. Istoria tehnologiei e plină de exemple similare: bucket-uri S3 publice care au expus dosare militare, baze de date MongoDB fără parolă care au scos la iveală cereri de viză și dosare clasificate, servere Elasticsearch neprotejate cu scanuri de permis de conducere și date ale copiilor. Diferența acum este viteza și scala la care aceste configurații greșite apar, alimentate de unelte AI care scriu cod mai repede decât orice om ar putea citi și audita.
Pentru utilizatorii finali, consecințele sunt reale: furto de identitate, phishing țintit, chantaj, expunere a vieții private. Pentru companii, riscurile includ sancțiuni GDPR/CCPA, daune de reputație irecuperabile, și acțiuni legale. Pentru ecosistemul de dezvoltare, credibilitatea platformelor "low-code/no-code/AI-first" depinde de capacitatea lor de a preveni catastrofele generate de propriile lor ușurințe.
De ce este important:
Această investigație evidențiază o criză sistemică în modul în care software-ul este construit astăzi: democratizarea dezvoltării prin AI a depășit capacitatea de a securiza ceea ce se construiește. Supabase nu este vinovată pentru greșelile clienților, dar are puterea — și, mulți argumentează, obligația morală — de a proiecta guardrails care să facă imposibil sau extrem de greu să expui date sensibile din greșeală. Până când platformele vor trata securitatea nu ca o "opțiune avansată" ci ca o cerință de bază impusă tehnic, vom continua să vedem undă după undă de breach-uri evitate, alimentate de viteza vibe coding-ului și lipsa de experiență a noilor generări de constructori. Pentru oricine lansează un produs astăzi: activați RLS, rotați cheile, auditați permisiunile, și nu vă fiți pe mesajele de avertizare din dashboard. Datele utilizatorilor voștri nu sunt un cost al afacerii — sunt o responsabilitate.
