16.326 baz Supabase je bilo berljivih brez prijave: težava je bila v nastavitvah

UpGuard je v raziskavi dostopa do baz Supabase med približno 300.000 domenami z znaki uporabe te storitve našel 16.326 baz z vsaj eno tabelo, ki jo je bilo mogoče brati brez prijave; pri več kot polovici teh baz je zgradba tabel nakazovala možnost dostopa do osebnih podatkov. Ugotovitev zadeva nastavitve posameznih projektov. Prijavni zaslon aplikacije namreč ne prepreči branja prek podatkovnega vmesnika, če pravila v bazi anonimni zahtevi dopuščajo dostop.

TechCrunch je o ugotovitvah poročal 25. septembra 2026 in objavil odziv vodje varnosti družbe Supabase Bila Harmerja, ki je projekte opisal kot »secure by default« ter poudaril, da stranke same upravljajo njihove nastavitve. Za razvijalca je odločilno, kaj podatkovni vmesnik vrne zahtevi brez uporabniške seje. Delujoča prijava in pravilno prikazani podatki po prijavi tega vprašanja ne razrešijo.

Kaj je raziskava štela kot berljivo bazo

Raziskovalci so iskali znake uporabe Supabase v javnih datotekah spletnih aplikacij. Pri najdenih projektih so podatkovni vmesnik vprašali po tabeli z uporabniki. Odgovor je lahko pomenil, da podatki niso dostopni, vrnil stran zapisov ali pa nakazal ime druge dostopne tabele. Zadnja možnost je pomembna: skrito ali neobičajno ime tabele samo po sebi ne omeji dostopa, kadar pravice dovoljujejo branje.

Štetje zajema baze, v katerih je bila berljiva najmanj ena tabela, ne vseh tabel v posamezni bazi. Raziskovalci so pri večini obseg morebitno občutljivih podatkov ocenili iz zgradbe tabel, ne s prenosom vseh vrstic. Podrobneje preverjeni primeri so pokazali tudi dejansko berljive zapise: pri ameriški storitvi parkiranja so bili med njimi podatki o strankah in registrske tablice, pri kanadski storitvi za priseljevanje pa tudi gesla, shranjena kot navadno besedilo. Samo število baz ne pove, kdo je do podatkov dostopal pred raziskavo.

Kako nastavitve obidejo prijavni zaslon

Odjemalska aplikacija lahko za povezavo s Supabase uporablja javni projektni ključ. Njegova prisotnost v kodi, ki jo prejme brskalnik, je predvidena; varnost je odvisna od dovoljenj in pravil za podatke, dosegljiva s tem ključem. Zahteva brez prijavljenega uporabnika nastopa z vlogo anon. Če ima ta vloga dovoljenje za branje tabele v izpostavljeni shemi in tabela nima ustrezne zaščite, lahko vmesnik vrne zapise mimo zaslona, na katerem aplikacija zahteva prijavo.

Zaščita na ravni vrstic, Row Level Security oziroma RLS, določa, katere vrstice lahko posamezna vloga vidi ali spremeni. Pomembni sta dve ločeni nastavitvi: dovoljenje vlogi za operacijo nad tabelo in pravilo RLS, ki omeji vrstice. Vključen RLS zato še ni zagotovilo zasebnosti, če pravilo anonimni vlogi dovoljuje branje vseh vrstic. Takšno pravilo je lahko primerno za javno objavljene podatke, ne pa za zasebne profile ali naročila.

Razlika nastane že pri ustvarjanju tabel. Urejevalnik tabel v Supabase za novo tabelo RLS privzeto vključi, tabela, ustvarjena z ukazom SQL, migracijo ali prek API, pa te nastavitve ne dobi nujno. Projekt ima lahko zato povsem delujočo prijavo, medtem ko je tabela, dodana po drugi poti, dosegljiva tudi anonimni vlogi. Enako preverjanje je potrebno, kadar shemo ustvarja orodje za pisanje kode: način nastanka tabele vpliva na začetno nastavitev, njena dejanska pravila pa določajo dostop.

Varen pregled lastnega projekta

Pregled naj zajame tabele, njihove pravice in odgovor podatkovnega vmesnika. Uradni produkcijski kontrolni seznam Supabase priporoča pregled Security Advisorja ter RLS in pravil za tabele. Opozorilo v nadzorni plošči je uporabno izhodišče, vendar je treba pri vsaki tabeli ugotoviti tudi, ali je anonimno branje zanjo namenoma dovoljeno.

1. V projektu, ki ga upravljate, popišite tabele v shemi public in morebitnih drugih shemah, ki ste jih izpostavili podatkovnemu vmesniku. Ob vsaki zapišite, ali vsebuje podatke, namenjene neprijavljenim obiskovalcem. Tako boste ločili javno vsebino od tabel, pri katerih bi bil enak odgovor vmesnika razkritje.
2. Za vsako dosegljivo tabelo preverite, ali je RLS vključen, kakšna dovoljenja imata vlogi anon in authenticated ter kaj določajo pravila za branje in spreminjanje. Posebej poglejte pravila, ki anonimni vlogi dovolijo vse vrstice. Prisotnost pravila je manj pomembna od tega, katere zapise dejansko prepusti.
3. V Security Advisorju preglejte opozorila in jih povežite s konkretnimi tabelami. Če je bila tabela dodana z migracijo ali ukazom SQL, preverite njene nastavitve neposredno, tudi če druge tabele iste aplikacije že uporabljajo RLS. Pregled ponovite po spremembah sheme, saj lahko nova tabela uvede drugačna začetna dovoljenja.
4. Dostop preverite še brez uporabniške seje, z javnim projektnim ključem in samo na svojem projektu. Uporabite preskusno okolje ter namenski, neobčutljiv zapis: anonimna zahteva naj pokaže, ali ga je mogoče prebrati. Med preverjanjem ne prenašajte ali izvažajte resničnih osebnih podatkov in ne poizvedujte po tujih bazah.

Če anonimna zahteva vrne zaseben zapis, popravite dovoljenja in pravila prizadete tabele, nato enako zahtevo ponovite. Preverite tudi dostop prijavljenega uporabnika, da sprememba ohrani predvideno delovanje aplikacije in mu ne odpre tujih zapisov. Pri tabeli, ki je bila že javno berljiva, ločeno ocenite, kateri podatki so bili dosegljivi in kaj o preteklem dostopu sploh kažejo razpoložljivi dnevniki.

Popravljena pravila lahko ustavijo nadaljnje nedovoljeno branje, sama sprememba pa ne razkrije, ali je kdo podatke prej že pridobil. Za lastnika prizadetega projekta je zato poleg ponovnega preskusa pomemben natančen popis dosegljivih tabel in vrst podatkov, ki so jih vsebovale.

Preberite tudi:

• Europass CV: en življenjepis za vse prijave je napačna bližnjica
• Izbris My Activity ne izbriše vsega: tako nastavite pravo samodejno brisanje
• Delo od doma: dogovor ni dovolj brez obvestila in varnih pogojev