Ujawnienie danych w Supabase podważa deklaracje bezpieczeństwa aplikacji tworzonych metodą vibe coding

Supabase znalazł się pod lupą po tym, jak badacze zidentyfikowali 16 326 baz danych z tabelami dostępnymi publicznie do odczytu, mimo że platforma opisuje swoje projekty jako domyślnie bezpieczne. Ustalenia dotyczące ujawnienia danych w Supabase łączą znany problem bezpieczeństwa chmury z nowszym źródłem ryzyka: aplikacjami szybko składanymi przy użyciu narzędzi do programowania z AI.

UpGuard znalazł oznaki obecności danych osobowych w ponad połowie ujawnionych baz danych. Według doniesień rekordy obejmowały imiona i nazwiska, adresy, numery telefonów, daty urodzenia, hasła, tokeny uwierzytelniające, prywatne wiadomości, numery rejestracyjne pojazdów oraz informacje imigracyjne.

Nie doszło tu do pojedynczego naruszenia wewnętrznych systemów Supabase. Dowody wskazują raczej na bazy danych klientów ujawnione wskutek braku lub niewystarczających mechanizmów kontroli dostępu. To rozróżnienie jest istotne, ale nie zmniejsza skali obaw.

Raport przekształca techniczną awarię konfiguracji w test modelu vibe coding. Asystenci AI mogą w ciągu kilku minut wygenerować działający interfejs i połączyć go z hostowaną bazą danych. Nie zapewniają jednak niezawodnie, że każdy użytkownik, tabela, rola i operacja otrzymają właściwą politykę autoryzacji.

Co wykazało badanie dotyczące ujawnienia danych w Supabase

Kluczowym ustaleniem UpGuard nie jest jedna wyjątkowo niedbała aplikacja, lecz tysiące niezależnie tworzonych projektów powtarzających podobne błędy bezpieczeństwa.

W ramach śledztwa z września 2026 r. UpGuard zebrał około 300 000 unikalnych domen wykazujących oznaki korzystania z Supabase. Badacze wykorzystali dane z BuiltWith oraz Chrome User Experience Report, aby zidentyfikować odpowiednie witryny.

Następnie sprawdzili, czy każdy projekt ujawniał tabelę o nazwie users. Ta powszechna nazwa tabeli dała badaczom spójny punkt wyjścia bez konieczności wcześniejszej znajomości struktury bazy danych każdej aplikacji.

Test dawał kilka możliwych odpowiedzi. Bezpieczna lub nieaktywna baza danych nie zwracała dostępnych danych. Niektóre bazy ujawniały inną dostępną tabelę poprzez podpowiedź błędu. Inne zwracały stronę rekordów.

W całym tym zbiorze kandydatów UpGuard zidentyfikował 16 326 baz danych z tabelami dostępnymi do odczytu. Według badania ujawnień firmy ponad połowa zawierała pola schematu sugerujące jakąś formę danych umożliwiających identyfikację osoby.

Badacze analizowali głównie schematy tabel, zamiast pobierać każdy dostępny rekord. Schemat ujawnia nazwy kolumn i typy danych, co może wskazywać, czy tabela zawiera adresy e-mail, hasła, numery telefonów lub informacje płatnicze.

Takie podejście ograniczyło niepotrzebny dostęp do danych osobowych. Oznacza też, że liczba 16 326 nie dowodzi, iż każda baza danych zawierała wrażliwe informacje ani że atakujący wcześniej skopiowali dostępne dane.

UpGuard zbadał wybrane przypadki, w których metadane sugerowały istotne ujawnienie. Przykłady pokazują, jak błąd konfiguracji może przejść od długu technicznego do bezpośredniej szkody dla osób fizycznych.

Jedna indyjska usługa transmisji dla dorosłych ujawniła tabelę zawierającą dane 65 467 osób. Pola miały obejmować dokumenty tożsamości, adresy, daty urodzenia, rachunki finansowe oraz częściowe numery identyfikacyjne wydawane przez państwo. Inna tabela zawierała ponad 100 000 prywatnych wiadomości z udziałem twórców treści.

Operator wirtualnych kart SIM na Filipinach ujawnił informacje o ponad 2 000 użytkowników i ponad 100 000 wiadomości tekstowych. Większość wiadomości zawierała jednorazowe kody dostępu, lecz próbka obejmowała także tysiące zwykłych komunikatów między kierowcami usług przewozowych a pasażerami.

Usługa parkingowa z USA ujawniła rekordy dotyczące ponad 100 000 klientów. Jej baza danych obejmowała około 78 000 numerów rejestracyjnych, około 43 000 adresów e-mail, historię wizyt, informacje o napiwkach oraz notatki w formie swobodnego tekstu.

Badacze znaleźli również bazę danych afrykańskiego konsulatu rządowego zawierającą 25 000 rekordów. Niektóre wpisy wskazywały lokalizacje mieszkań awaryjnych osób należących do potencjalnie szczególnie narażonej populacji.

Kanadyjska usługa imigracyjna ujawniła niemal 5 000 rekordów. UpGuard podał, że 884 z nich zawierały hasła przechowywane w postaci jawnego tekstu, co oznacza, że aplikacja zawiodła zarówno w zakresie kontroli dostępu, jak i obsługi haseł.

Przypadki te wspierają szerszy wniosek, a zarazem ujawniają różne warstwy niepowodzeń. Publiczny dostęp do tabel otworzył drzwi, ale słaba konstrukcja aplikacji uczyniła ich zawartość bardziej niebezpieczną.

Oryginalny artykuł wskazywał, że większość dotkniętych zbiorów danych wydawała się powiązana ze Stanami Zjednoczonymi. UpGuard mimo to znalazł ujawnione projekty na całym świecie i opisał problem jako globalny.

Rozprzestrzenienie geograficzne ma znaczenie, ponieważ Supabase pełni rolę wspólnej infrastruktury dla małych aplikacji, nowych firm i uznanych organizacji. Jeden powtarzający się wzorzec konfiguracji może zatem dotknąć niepowiązanych użytkowników w kilku branżach i jurysdykcjach prawnych.

Dlaczego baza danych była dostępna z internetu

Publiczny klucz w aplikacji Supabase nie musi sam w sobie stanowić luki. Decydująca jest kontrola tego, co wolno zrobić przy użyciu tego klucza.

Supabase udostępnia hostowaną bazę PostgreSQL wraz z uwierzytelnianiem, pamięcią masową i automatycznie generowanymi interfejsami danych. Aplikacja internetowa może wysyłać żądania przez Data API, korzystając z klucza publikowalnego.

Programiści czasem zakładają, że znalezienie tego klucza w kodzie przeglądarki dowodzi jego wycieku. Supabase wyraźnie projektuje klucze publikowalne dla klientów publicznych, w tym witryn internetowych i aplikacji mobilnych.

Rzeczywista ochrona wynika z uprawnień i Row Level Security, zwykle skracanego do RLS. RLS to funkcja PostgreSQL, która stosuje reguły autoryzacji wewnątrz bazy danych przed zwróceniem lub zmianą poszczególnych wierszy.

Zalogowany użytkownik może otrzymać uprawnienie do odczytu tylko rekordów zawierających identyfikator tego użytkownika. Wylogowany odwiedzający może nie otrzymać dostępu w ogóle. Inna polityka może pozwolić wszystkim na odczyt celowo publicznego katalogu produktów.

Dokumentacja bezpieczeństwa Supabase mówi, że programiści muszą włączyć RLS dla udostępnionych tabel i skonfigurować polityki zgodnie z zasadą najmniejszych uprawnień. Klucz publikowalny uznaje się za bezpieczny wyłącznie wtedy, gdy te mechanizmy prawidłowo ograniczają dostęp.

Platforma zapewnia także tajne klucze lub klucze service-role dla zaufanych systemów backendowych. Te klucze omijają RLS i nigdy nie mogą pojawić się w przeglądarce, dostarczonej aplikacji ani publicznym repozytorium.

Ta architektura tworzy subtelną granicę bezpieczeństwa. Widoczny klucz publikowalny jest oczekiwany, ale jednocześnie daje nieuwierzytelnionemu odwiedzającemu drogę do wszystkiego, do czego baza danych pozwala uzyskać dostęp roli anon.

Jeśli tabela nie ma RLS, ma nadmierne uprawnienia lub korzysta z polityki zezwalającej na dostęp do każdego wiersza, osoba z zewnątrz może ją odpytywać przez ten sam interfejs, z którego korzysta legalna aplikacja. Nie jest potrzebne żadne zaawansowane włamanie.

Badacze UpGuard znajdowali docelowe projekty, analizując publicznie dostarczany JavaScript pod kątem identyfikatorów Supabase. Następnie mogli zapytać każdą bazę danych, czy wspólna tabela była dostępna przez jej publiczny interfejs.

Technika ta przypomina zwykłe zachowanie aplikacji. Różnica polega na tym, kto wysyła żądanie i czy baza danych potrafi odróżnić uprawnionego użytkownika od dowolnej innej osoby w internecie.

Szczegółowe wytyczne RLS Supabase ostrzegają, że tabela w udostępnionym schemacie może być możliwa do odczytu lub zapisu, gdy RLS jest nieobecne, a rola wysyłająca żądanie ma odpowiednie uprawnienia. Zalecają testowanie zarówno dozwolonych, jak i odrzuconych operacji dla ról anonimowych i uwierzytelnionych.

Dlatego sama rotacja klucza publikowalnego nie rozwiązuje podstawowego problemu. Nowy klucz nadal można pobrać z klienta, podczas gdy wadliwa polityka bazy danych wciąż przyznaje dostęp.

Zamiast tego programiści muszą przejrzeć udostępnione schematy, uprawnienia tabel, status RLS, warunki polityk, widoki bazy danych oraz poświadczenia serwerowe. Potrzebują też testów potwierdzających, że użytkownicy nie mogą odczytywać ani zmieniać rekordów innych użytkowników.

Widoki zasługują na szczególną uwagę. Widoki PostgreSQL mogą domyślnie oceniać uprawnienia przez swojego właściciela, potencjalnie omijając ograniczenia chroniące bazowe tabele. Projekt może więc włączyć RLS wszędzie, a mimo to ujawniać dane przez niebezpieczny widok.

To samo rozróżnienie dotyczy uwierzytelniania. Wymaganie od kogoś zalogowania się nie zapewnia automatycznie separacji dzierżawców. Każdy uwierzytelniony użytkownik może nadal uzyskać szeroki dostęp, jeśli polityka sprawdza jedynie poprawność sesji.

Bezpieczeństwo Supabase wyjaśnione na poziomie klucza jest więc proste. Klienci publiczni potrzebują publicznego identyfikatora, a polityki bazy danych egzekwują rzeczywistą granicę. Trudność polega na przełożeniu zamierzonych reguł aplikacji na kompletne, przetestowane polityki.

Vibe coding zamienia lukę konfiguracyjną w powtarzalny wzorzec

Ryzyko bezpieczeństwa związane z vibe coding rośnie, gdy asystent AI optymalizuje widoczny rezultat, podczas gdy autoryzacja pozostaje ukryta przed osobą nim kierującą.

Tradycyjny zespół programistyczny również może błędnie skonfigurować bazę danych. Publiczne zasobniki Amazon S3, ujawnione klastry Elasticsearch i wyciekłe poświadczenia chmurowe istniały na długo przed wejściem generatywnej AI do tworzenia oprogramowania.

W przypadku vibe coding zmienia się połączenie szybkości, dostępności i ograniczonego przeglądu. Osoba może poprosić o aplikację w języku naturalnym, zaakceptować wygenerowany kod, podłączyć hostowany backend i wdrożyć rozwiązanie bez zrozumienia granic zaufania.

Aplikacja może sprawiać wrażenie kompletnej, ponieważ rejestracja działa, rekordy zapisują się poprawnie, a strony się ładują. Testy te potwierdzają funkcjonalność. Nie potwierdzają, że jedno konto nie może odpytać rekordów innego konta.

Błędy autoryzacji szczególnie łatwo przeoczyć podczas prezentacji przebiegającej zgodnie z oczekiwanym scenariuszem. Programista widzi oczekiwany profil po zalogowaniu i zakłada, że system go chroni. Atakujący zadaje inne pytanie: co się dzieje, gdy żądanie nie zawiera sesji lub zmienia identyfikator rekordu?

Agenci programistyczni AI także programowo współdziałają z infrastrukturą. UpGuard zauważył, że Supabase domyślnie włącza RLS dla tabel tworzonych za pośrednictwem części panelu, podczas gdy tabele tworzone programowo wymagają dodatkowej ostrożności.

Ta różnica może mieć istotne konsekwencje, gdy agent tworzy schemat bazy danych przez SQL lub API. Ustawienie ochronne powiązane z jednym procesem tworzenia nie obejmuje automatycznie wszystkich ścieżek prowadzących do platformy.

Supabase przyznał istnienie tego szerszego wyzwania związanego z użytecznością w swoim przeglądzie bezpieczeństwa z 2025 r.. Firma stwierdziła, że RLS jest elastyczny, ale może być złożony dla programistów, którzy dopiero poznają ten wzorzec.

W 2025 r. Supabase dodał bezpieczniejsze ustawienia domyślne i rozbudował Security Advisor. Dał też projektom większą kontrolę nad Data API, w tym możliwość jego wyłączenia lub udostępnienia własnego schematu zamiast domyślnego schematu public.

Zmiany te pomagają, ale nie usuwają istniejących projektów ani nie naprawiają każdej wygenerowanej migracji. Narzędzia bezpieczeństwa mogą oznaczać częste błędy, jednak polityka może pozostać logicznie błędna, jednocześnie przechodząc podstawową kontrolę.

Wygenerowana reguła może porównywać niewłaściwy identyfikator, pomijać ścieżkę aktualizacji albo chronić odczyty, jednocześnie zezwalając na nieautoryzowane zapisy. Może działać dla jednej tabeli, ale pozostawić powiązaną tabelę publiczną.

Człowiek nadzorujący agenta musi rozpoznać, że brakuje określonego zachowania. Początkujący, który nie zna RLS, uprawnień ról ani izolacji tenantów, może nigdy nie poprosić modelu o ich przetestowanie.

Tworzy to asymetrię między budowaniem a audytem. Wygenerowanie funkcji wymaga jednego promptu. Udowodnienie, że funkcja bezpiecznie obsługuje każdą tożsamość i operację, wymaga modelu zagrożeń, testów negatywnych oraz starannej analizy wygenerowanych artefaktów.

Wcześniejsze badania sugerują, że jest to powtarzający się wzorzec, a nie odosobniony wynik ankiety. UpGuard przywołał badania obejmujące firmy z Y Combinator, aplikacje tworzone za pośrednictwem platform programistycznych AI oraz niezależne strony.

Modern Pentest podał, że 28 procent spośród 107 zbadanych startupów Y Combinator ujawniało dane osobowe za pośrednictwem konfiguracji Supabase. Inne badanie przeanalizowało 1 072 aplikacje tworzone metodą vibe coding i znalazło 39 z tabelami możliwymi do odczytu za pomocą publicznego klucza Supabase.

Próbki i metody różnią się, więc nie należy łączyć ich odsetków. Każde dochodzenie wykazało jednak odmiany tego samego problemu: widoczne po stronie klienta dane połączenia połączone z uprawnieniami bazy danych szerszymi, niż zamierzała aplikacja.

Incydent z lutego 2026 roku szczególnie uwidocznił konsekwencje. Firma bezpieczeństwa Wiz odkryła, że Moltbook, sieć społecznościowa przedstawiana jako platforma dla agentów AI, miała błędnie skonfigurowany backend Supabase.

Według dochodzenia dotyczącego Moltbook, baza danych umożliwiała odczyt i zapis danych platformy. Ujawnione materiały obejmowały 35 000 adresów e-mail oraz 1,5 miliona tokenów uwierzytelniających API.

Wiz poinformował, że wykrył problem podczas przeglądu JavaScriptu po stronie klienta w ramach nieinwazyjnej oceny. Zespół Moltbook zabezpieczył bazę danych w ciągu kilku godzin od zgłoszenia.

Ten epizod stanowił zwięzły przykład obecnego kompromisu. Pomoc AI ułatwiła stworzenie usługi, która szybko przyciągnęła uwagę, lecz widoczny sukces aplikacji ukrywał krytyczną awarię kontroli bazy danych.

Dla organizacji oceniających oprogramowanie zbudowane przy użyciu AI zmienia to znaczenie działającego prototypu. Demonstracja mówi teraz mniej o gotowości produkcyjnej, ponieważ AI może ukończyć widoczne przepływy pracy, zanim ktokolwiek zweryfikuje leżący pod nimi model bezpieczeństwa.

Wewnętrzna baza wiedzy inżynieryjnej może pomóc zespołom zachować decyzje architektoniczne i dowody z przeglądów. Nie zastąpi testów bazy danych, lecz może zapobiec zanikaniu założeń bezpieczeństwa między promptami i przekazaniami pracy.

„Bezpieczne domyślnie” kontra współdzielona odpowiedzialność

Główny konflikt dotyczy bezpiecznych ustawień domyślnych platformy oraz modelu współdzielonej odpowiedzialności, który nadal pozostawia niedoświadczonym klientom kontrolę nad istotnymi ustawieniami.

Dyrektor ds. bezpieczeństwa informacji Supabase, Bil Harmer, powiedział TechCrunch, że firma nie zapoznała się z badaniem UpGuard przed skomentowaniem go. Stwierdził, że projekty Supabase są bezpieczne domyślnie, i opisał bezpieczeństwo jako wspólną odpowiedzialność.

Stanowisko to odzwierciedla standardowy model chmurowy. Dostawca zabezpiecza hostowaną platformę i oferuje mechanizmy kontroli dostępu. Klienci decydują, którzy użytkownicy i aplikacje powinny mieć dostęp do ich danych.

To rozróżnienie jest zasadne. UpGuard nie zgłosił naruszenia systemów korporacyjnych Supabase ani obejścia prawidłowo skonfigurowanej polityki RLS. Ujawnione bazy danych należały do klientów, których ustawienia dopuszczały szerszy dostęp.

Ustawień domyślnych nie można jednak oceniać wyłącznie w chwili tworzenia projektu. Obejmują one również praktyczne ścieżki, którymi ludzie i agenci programistyczni tworzą tabele, publikują API, kopiują przykłady i wdrażają aplikacje.

System może zacząć w bezpiecznym stanie, a później zostać ujawniony przez migrację wygenerowaną przez agenta. Może również oferować bezpieczny przepływ pracy w panelu, podczas gdy przepływ programistyczny tworzy inny stan bezpieczeństwa.

Określenie „bezpieczne domyślnie” wymaga zatem zdefiniowanej granicy. Czy oznacza, że nowy projekt niczego nie ujawnia? Czy obejmuje każdą obsługiwaną ścieżkę tworzenia tabel? Czy ostrzega użytkowników, zanim dane produkcyjne trafią do tabeli bez RLS?

Współdzielona odpowiedzialność zakłada również, że każda strona rozumie swój zakres obowiązków. Doświadczeni inżynierowie chmurowi wiedzą, że publiczny identyfikator klienta musi być połączony z autoryzacją po stronie serwera. Wielu twórców vibe coding tego nie wie.

Ta luka wiedzy nie czyni platformy wyłącznie odpowiedzialną za błędy klientów. Zwiększa jednak presję na Supabase i dostawców AI do programowania, by niebezpieczne stany były trudniejsze do utworzenia i łatwiejsze do wykrycia.

Platforma już podąża w tym kierunku. Security Advisor Supabase sprawdza typowe problemy z bazą danych, a jego lista kontrolna dla środowiska produkcyjnego nakazuje użytkownikom włączyć RLS we wszystkich odpowiednich tabelach i przeglądać polityki.

Bardziej rygorystyczna konstrukcja mogłaby blokować produkcyjny dostęp do niezabezpieczonej tabeli albo wymagać wyraźnego nadpisania tej blokady. Takie środki ograniczyłyby przypadkowe ujawnienia, ale mogłyby również utrudniać korzystanie z uzasadnionych publicznych zbiorów danych i szybki rozwój.

Supabase musi równoważyć te przypadki, nie traktując każdej publicznej tabeli jako podatności. Menu restauracji, publiczna tabela wyników lub opublikowany katalog mogą zasadnie zezwalać na anonimowy odczyt.

Platforma nie może wywnioskować intencji wyłącznie z nazwy tabeli. Tabela users jest bardziej podejrzana niż products, lecz aplikacja może celowo publikować profile użytkowników, zachowując prywatność adresów e-mail.

Narzędzia automatyczne napotykają tę samą niejednoznaczność. Mogą wykryć, że anonimowa rola może odczytać tabelę. Ustalenie, czy dostęp narusza obietnicę produktu, wymaga kontekstu biznesowego.

To jest istota kompromisu. Elastyczne polityki baz danych pozwalają deweloperom tworzyć wiele rodzajów aplikacji, ale elastyczność stwarza miejsce na ciche błędy. Restrykcyjne ograniczenia zapobiegają błędom, jednocześnie ograniczając uzasadnione projekty.

Asystenci AI dodają kolejną odpowiedzialną stronę. Deweloper może wybrać Supabase, ponieważ polecił go agent, a następnie polegać na tym agencie przy generowaniu schematu i polityk.

Dostawca modelu nie hostuje bazy danych, podczas gdy Supabase nie kontroluje każdego wygenerowanego polecenia. Właściciel aplikacji pozostaje odpowiedzialny wobec użytkowników, nawet gdy nie potrafi wyjaśnić wynikowego modelu autoryzacji.

Ten rozproszony łańcuch sprawia, że awarie bezpieczeństwa trudniej przypisać i łatwiej powtarzać. Każdy uczestnik może wskazywać dokumentację lub konfigurację innej strony, podczas gdy osoba dotknięta problemem widzi jedynie, że prywatne informacje stały się publiczne.

Dla nabywców korporacyjnych praktyczną odpowiedzią jest ocena całego systemu rozwoju. Certyfikaty dostawców mają znaczenie, ale istotne są także kontrola wdrożeń, przegląd kodu, testy bazy danych, rejestrowanie zdarzeń, reagowanie na incydenty oraz doświadczenie osób nadzorujących agentów AI.

Co pokazują liczby, a czego nie pokazują

Badanie wskazuje na dużą powierzchnię ekspozycji, lecz jego metodologia nie potwierdza 16 326 naruszeń ani nie mierzy całej bazy klientów Supabase.

UpGuard rozpoczął od domen wykazujących oznaki użycia Supabase, a nie od losowej próby wszystkich aplikacji na platformie. Jego źródła faworyzowały witryny widoczne w zbiorach danych o technologiach internetowych.

Następnie badacze wyszukiwali tabelę o nazwie users. Wybór ten był rozsądny, ponieważ wiele aplikacji utrzymuje dane użytkowników, lecz ukierunkował ankietę również na bazy danych, które prawdopodobnie zawierają dane osobowe.

UpGuard ujawnił to ograniczenie. Firma stwierdziła, że jej wyniki były przesunięte w stronę PII częściowo dlatego, że celowo wybrała powszechną tabelę powiązaną z ludźmi.

Łączna liczba 16 326 obejmuje bazy danych udostępniające tabele do odczytu. Nie oznacza to, że każda tabela zawierała poufne rekordy. Niektóre projekty mogły celowo publikować dane, wykorzystywać informacje syntetyczne albo zostać porzucone.

Analiza schematu mierzy potencjalną ekspozycję inaczej niż śledztwo kryminalistyczne analizujące rekord po rekordzie. Kolumna o nazwie password jest poważnym ostrzeżeniem, lecz samo jej istnienie nie dowodzi, że zawierała aktywne poświadczenia.

Badacze ręcznie zweryfikowali wybrane przypadki i podali konkretne liczby rekordów z tych baz danych. Przykłady te pokazują, że przynajmniej niektóre ekspozycje obejmowały rzeczywiste, wrażliwe dane na istotną skalę.

Badanie nie może również określić, ilu zewnętrznych użytkowników uzyskało dostęp do baz danych przed ujawnieniem problemu. Publiczna dostępność tworzy ryzyko, ale nie jest dowodem, że przestępcy odkryli lub pobrali te informacje.

Różnica ta oddziela ekspozycję danych od potwierdzonego naruszenia danych. Ekspozycja oznacza, że nieautoryzowany dostęp był możliwy. Naruszenie zazwyczaj wymaga dowodów, że nieuprawniona strona faktycznie uzyskała dostęp do danych lub je pozyskała.

Organizacje nie powinny wykorzystywać tego rozróżnienia do bagatelizowania zdarzenia. Gdy wrażliwe rekordy są dostępne bez odpowiedniej autoryzacji, śledczym może brakować wystarczających logów, aby udowodnić, kto uzyskał do nich dostęp.

Badanie nie wylicza również wskaźnika ekspozycji dla wszystkich projektów Supabase. UpGuard przeanalizował około 300 000 potencjalnych domen, podczas gdy jedna organizacja może obsługiwać wiele domen lub projektów.

Nieaktywne witryny i fałszywe wskaźniki technologiczne mogą komplikować ten mianownik. Końcową liczbę najlepiej rozumieć jako wykrytą populację, a nie odsetek klientów Supabase.

Nawet przy tych zastrzeżeniach 16 326 baz danych dostępnych do odczytu stanowi znaczną powierzchnię ataku. Złośliwy podmiot mógłby zautomatyzować ten sam ogólny proces wykrywania i priorytetyzować tabele zawierające cenne pola.

Szczegółowe przypadki osłabiają również argument, że były to nieszkodliwe projekty demonstracyjne. Rejestry imigracyjne, lokalizacje mieszkań awaryjnych, prywatna komunikacja osób dorosłych, tablice rejestracyjne oraz jednorazowe kody dostępu niosą wyraźne konsekwencje dla prywatności i bezpieczeństwa.

Odpowiedź Supabase zasługuje na równie precyzyjne ujęcie. Firma poinformowała, że powiadamia dotkniętych klientów, gdy dowiaduje się o problemach z bezpieczeństwem. Nie potwierdza to, ile projektów zostało powiadomionych, jak szybko zareagowały ani ile ekspozycji pozostało otwartych.

UpGuard poinformował, że zawiadomił właścicieli aplikacji w istotnych przypadkach, które zweryfikował. Jego raport publiczny nie przedstawił pełnego wskaźnika napraw dla wszystkich 16 326 baz danych.

Te luki powinny kształtować relacjonowanie ustaleń. Dowody wskazują na powszechny problem konfiguracji i kilka poważnych ekspozycji. Nie uzasadniają twierdzenia, że Supabase zostało zhakowane ani że każda zidentyfikowana baza danych ujawniła wrażliwe rekordy.

Pozostawiają także bez odpowiedzi ważne pytanie porównawcze. Porównywalne hostowane bazy danych mogłyby wykazywać podobne problemy, gdyby badacze zastosowali równoważną metodę na skalę całego internetu.

Firebase, Appwrite, samodzielnie zarządzane wdrożenia PostgreSQL i inne usługi backendowe udostępniają różne interfejsy oraz korzystają z różnych modeli uprawnień. Deweloperzy mogą błędnie skonfigurować każde z nich.

Supabase przyciąga uwagę, ponieważ jego architektura przyjazna klientom, automatyczne API i popularność w przepływach pracy AI do programowania uwidaczniają ten problem. Popularność zwiększa zarówno liczbę bezpiecznych wdrożeń, jak i liczbę błędów.

Rzetelna ocena powinna więc unikać przedstawiania Supabase jako platformy wyjątkowo niezdolnej do ochrony danych. Mocniejszy wniosek jest taki, że jego popularność wśród niedoświadczonych twórców sprawia, iż użyteczność kontroli dostępu staje się problemem na poziomie platformy.

Trzy sygnały pokażą, czy ryzyko maleje

Kolejną fazę należy oceniać poprzez mierzalne zmiany produktu, dowody napraw oraz niezależne ponowne testy, a nie szerokie obietnice bezpieczeństwa.

Pierwszym sygnałem jest sposób, w jaki Supabase obsługuje tabele tworzone programowo. Agenci programistyczni często pracują za pomocą SQL, interfejsów zarządzania i zautomatyzowanych migracji, a nie ręcznych kliknięć w panelu.

Znacząca zmiana sprawiłaby, że RLS i restrykcyjne uprawnienia byłyby spójne we wszystkich ścieżkach tworzenia, albo wymagałaby wyraźnej decyzji, zanim tabela stanie się dostępna przez Data API. Jasne ostrzeżenia w przepływach pracy agentów wzmocniłyby tę ochronę.

Gdyby Supabase zniwelowało różnicę między tworzeniem projektów w panelu a programistycznie, wzmocniłoby to pogląd, że bezpieczniejsze ustawienia domyślne mogą ograniczać zagrożenia bezpieczeństwa związane z vibe codingiem. Jeśli te przepływy pracy pozostaną odmienne, niedoświadczeni twórcy nadal będą trafiać w niebezpieczne stany, nie zdając sobie z tego sprawy.

Drugim sygnałem są dane dotyczące naprawy problemów. Supabase i UpGuard mogą wyjaśnić, ile zidentyfikowanych projektów otrzymało powiadomienia, ilu właścicieli odpowiedziało oraz ile baz danych przestało ujawniać niezamierzenie udostępnione rekordy.

Wysoki wskaźnik napraw wskazywałby, że powiadomienia i narzędzia bezpieczeństwa mogą ograniczyć istniejące zaległości. Niski wskaźnik sugerowałby, że wiele projektów jest porzuconych, źle utrzymywanych lub prowadzonych przez osoby, które nie potrafią poprawić konfiguracji.

Dotknięte organizacje muszą również ustalić, czy ujawnione rekordy wymagają powiadomienia użytkowników lub zgłoszenia regulacyjnego. Decyzja ta zależy od lokalizacji, rodzaju danych, dowodów dostępu oraz obowiązującego prawa.

Trzecim sygnałem będą niezależne ponowne testy w ciągu najbliższych kilku miesięcy. Badacze powinni powtórzyć porównywalne skany i opublikować przejrzyste metody, które odróżniają celowo publiczne dane od wrażliwych ekspozycji.

Spadająca liczba baz danych wspierałaby strategię Supabase opartą na bezpieczniejszych ustawieniach domyślnych. Stabilna lub rosnąca liczba wskazywałaby, że rozwój platformy i wspomagane przez AI tworzenie oprogramowania generują niebezpieczne projekty szybciej, niż istniejące mechanizmy kontroli są w stanie je naprawić.

Dostawcy narzędzi do programowania z AI również zasługują na analizę podczas tych ponownych testów. Ich agenci powinni tworzyć polityki najmniejszych uprawnień, generować negatywne testy autoryzacji oraz ostrzegać, gdy wdrożenie ujawnia dane osobowe.

Programiści nie muszą rezygnować z Supabase ani programowania z AI, aby reagować odpowiedzialnie. Muszą traktować wygenerowane oprogramowanie jako niezaufane, dopóki jego mechanizmy autoryzacji nie zostaną przetestowane.

Oznacza to osobne sprawdzanie dostępu anonimowego i uwierzytelnionego, testowanie każdej operacji na bazie danych, przeglądanie widoków, ochronę kluczy serwerowych oraz wyłączanie interfejsów, których aplikacja nie potrzebuje.

Zespoły powinny także zachowywać decyzje stojące za tymi kontrolami. Przeszukiwalna baza wiedzy AI może połączyć wymagania, wygenerowane migracje, ustalenia audytu i działania naprawcze, nie sprowadzając dokumentacji do późniejszej refleksji.

Historia ujawnienia danych w Supabase dotyczy ostatecznie luki w rozliczalności. Platformy oferują konfigurowalne mechanizmy kontroli, agenci AI składają aplikacje, a użytkownicy ufają gotowemu interfejsowi.

Kto weryfikuje niewidoczne uprawnienia, zanim do systemu trafią prawdziwe informacje? Każda organizacja wdrażająca aplikację wygenerowaną przez AI powinna umieć odpowiedzieć na to pytanie wynikami testów, wskazanymi właścicielami i dowodami odmowy dostępu.