Peste 16.000 de baze de date Supabase malconfigurate expun tabele citibile cu date personale (PII), parole în clar și tokenuri de autentificare, potrivit unei analize a companiei de cyber risk management UpGuard, relatată de BleepingComputer (sursa). Nu este o vulnerabilitate a platformei Supabase, ci o problemă de configurare: lipsa sau ineficiența politicilor de row-level security și folosirea greșită a cheilor publice. Cercetătorii notează că nu pot stabili că fiecare site afectat a fost construit de un agent AI, deși identifică această corelație ca fir roșu probabil.

Problema nu ține de un tip anume de business. UpGuard spune explicit că setările de securitate sunt invariante față de tipul de business, pentru că oamenii care își cunosc foarte bine nișa nu își înțeleg configurația bazei de date. Firul comun, în observația lor, este că site-urile sunt create de agenți de cod AI, iar oamenii nu sunt conștienți de configurație. Aici e miezul discuției de operator: nu AI-ul scrie cod prost, ci nimeni nu verifică ce a scris. Iar verificarea nu e o muncă de marketing, e o muncă de infrastructură.

Ce s-a găsit concret în cele 16.000 de baze de date

UpGuard a analizat un set de circa 300.000 de domenii care prezentau semne de utilizare Supabase și a verificat existența unui tabel „users”. Unele interogări returnau o pagină din baza de date, altele indicau că tabelul „users” nu există, dar un alt tabel era accesibil. Cercetătorii au folosit apoi schemele tabelelor pentru a deduce tipurile de date expuse.

În peste jumătate dintre bazele de date expuse au apărut informații de identificare personală, iar un subset mai mic includea parole și tokenuri de autentificare. Din analiza schemelor, UpGuard consideră că o parte foarte mică a informațiilor expuse include date de card de credit, ceea ce nu înseamnă că riscul e mic, ci că e concentrat.

Câteva cazuri ilustrează amploarea:

UpGuard spune că a notificat proprietarii aplicațiilor atunci când analiza aprofundată a identificat expunere semnificativă. Recomandarea pentru utilizatorii Supabase este să parcurgă documentația de securitate a platformei, inclusiv advisorii și ghidul de securitate API, pentru a identifica și remedia riscurile.

De ce Supabase, de ce acum, de ce AI-ul nu e vinovatul principal

Supabase este o platformă open-source construită în jurul PostgreSQL, care oferă servicii de backend pentru a construi și lansa aplicații și site-uri mai rapid. A devenit populară mai ales în rândul dezvoltatorilor care folosesc instrumente AI pentru a construi proiecte: peste 60% dintre bazele de date nou create provin din dezvoltare asistată de AI, conform datelor citate în material.

Aici e nuanța care contează pentru oricine citește știrea în grabă. O platformă de backend cu API public expune date doar dacă politicile de acces sunt configurate greșit. Row-level security este mecanismul prin care stabilești cine vede ce rând din ce tabel. Dacă îl lași deschis sau folosești o cheie publică pentru operații care ar trebui să fie protejate, oricine poate citi tabele.

Un agent AI care generează rapid un MVP de aplicație nu verifică implicit dacă politicile tale de securitate sunt corecte. El livrează cod funcțional, iar „funcțional” și „sigur” nu sunt sinonime. Asta nu transformă AI-ul în cauza expunerii. Transformă lipsa unui pas de verificare într-o vulnerabilitate de producție.

Verificări pe care le faci înainte să acuzi sau să ignori

Nu avem acces la datele UpGuard și nu este studiul nostru. Ce putem face este să separăm clar constatările măsurate de ipoteze. UpGuard a măsurat: 16.000 de baze de date expuse, peste jumătate cu PII, un subset cu parole și tokenuri, cazurile individuale enumerate mai sus. UpGuard nu a dovedit: că fiecare aplicație afectată a fost construită de un agent AI, nici cauzalitatea directă între AI și expunere.

Ce poți verifica tu, ca proprietar de produs sau de site, fără să presupui nimic:

  1. Intră în proiectul Supabase și verifică politicile de row-level security pe fiecare tabel care conține date de utilizator.
  2. Caută unde este folosită cheia publică (anon) și ce operații permite. Dacă poate citi tabele sensibile, ai o problemă de configurare, nu de platformă.
  3. Rulează advisorii de securitate din Supabase dacă sunt disponibili în proiectul tău și citește ghidul de securitate API.
  4. Verifică dacă tabelele care conțin parole sau tokenuri sunt accesibile în vreun mod din exterior.
  5. Consemnează rezultatul verificării, cu data și cine a făcut-o, ca să ai o urmă.

O verificare incompletă nu dovedește absența unei funcții sau a unei expuneri. Dacă nu ai acces la schema completă sau la jurnale, spune că verificarea e parțială, nu că „e ok”.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă ai un magazin online, un SaaS mic sau un site pe care un freelancer ți l-a construit peste un backend Supabase, riscul nu e teoretic. Un tabel de utilizatori accesibil public înseamnă date de client care pot fi citite, chiar dacă nu se întâmplă nimic rău astăzi. Nu poți afirma că ai pierdut bani sau că ai încălcat legea doar pe baza unei știri. Poți însă verifica și remedia.

Concret, pentru un operator de ecommerce:

Pentru un marketer care lucrează cu un dezvoltator extern, întrebarea de pus nu este „ai securizat baza de date?”, ci „arată-mi politicile de row-level security pe tabelul de utilizatori”. Un răspuns vag e un semnal. Un răspuns cu dump de configurație este dovadă.

Aici se leagă de discuția mai largă despre cum arată infrastructura pe care rulează marketingul în 2026. Când construiești pe date de client și pe automatizări, calitatea fundației tehnice decide dacă datele rămân ale tale, în sensul legal și operațional, în articolul despre SMS marketing în ecommerce și în cel despre cum utilizatorii nu mai dau click pe linkuri vezi exact aceeași logică: unelte bune montate pe o fundație necontrolată produc rezultate imprevizibile. Dacă lucrezi cu agenți AI care generează componente de voce sau backend, vLLM-Omni pe SageMaker arată cât de repede se adună straturi de infrastructură fără un control explicit al accesului.

Scenarii ipotetice și limite pe care le pui

Nu știm câte aplicații din România sunt afectate. Nimeni nu știe din materialul publicat. Orice cifră pe piața locală ar fi inventată. Ce putem face este să construim scenarii de lucru.

Scenariul 1: ai un SaaS mic, câțiva sute de utilizatori, backend Supabase, dezvoltat de un freelancer cu ajutor de AI. Ipoteză: politicile de acces ar putea fi incomplete. Pas: verificare manuală a politicilor și a cheilor.

Scenariul 2: ai un magazin online pe Shopify cu aplicații terțe care scriu într-o bază de date proprie. Ipoteză: datele de client ar putea fi duplicate în afara Shopify, fără aceleași protecții. Pas: inventarizarea locurilor unde ajung datele și revizuirea accesului.

Scenariul 3: colaborezi cu o agenție care a construit un landing cu formular conectat la o bază de date. Ipoteză: cheia publică ar putea fi folosită pentru citire. Pas: cererea unei dovezi de verificare, nu o promisiune.

Toate acestea rămân ipoteze până la verificare. Vestea bună e că remedierea e rapidă și ieftină dacă o faci înainte de incident. Vestea proastă e că nimeni nu o face pentru tine dacă nu întrebi.

FAQ

Este o vulnerabilitate în Supabase pe care trebuie să o patch-uiesc? Nu. Materialul descrie o problemă de configurare: lipsa sau ineficiența politicilor de row-level security și folosirea greșită a cheilor publice. Nu este un CVE sau un exploit în platformă. Verificarea se face în configurația proiectului tău.

Dacă folosesc un agent AI pentru a construi aplicația, sunt automat expus? Nu automat. UpGuard subliniază explicit că scanările lor nu stabilesc că fiecare site afectat a fost construit cu un agent AI. Corelația există în observațiile lor, dar cauzalitatea nu e dovedită. Verificarea configurației rămâne obligatorie indiferent cine a scris codul.

Ce fac dacă bănuiesc că am date expuse? Parcurge documentația de securitate Supabase, inclusiv advisorii și ghidul de securitate API, verifică politicile de row-level security pe tabelele cu date de utilizator și restrânge accesul cheilor publice la minimum necesar. Dacă nu poți interpreta singur configurația, cere ajutor tehnic înainte de a presupune că e ok.

AI-ul ajută, dar omul decide și execută

Unelte AI pot accelera construcția de aplicații, pot genera rapid scheme de baze de date și pot scurta timpul până la primul MVP. Asta e partea utilă. Dar un MVP care expune date de client nu e un produs, e o problemă amânată. Verificarea configurației, decizia despre ce date sunt expuse și cine are acces rămân pași umani, făcuți de un om responsabil, fie că e dezvoltator, fie că e media buyer sau operatorul care răspunde de produs.

La ALLSoft Agency tratăm aceste lucruri ca pe un pas de execuție, nu ca pe o teorie. Verificăm fundația tehnică pe care rulează campaniile și automatizările, pentru că datele de client nu sunt o detaliu de infrastructură, sunt activul tău. Dacă vrei o verificare aplicată pe proiectul tău, discutăm concret pe allsoftagency.ro.