Ponad 16 tysięcy źle skonfigurowanych baz Supabase ujawniało dane osobowe, hasła i tokeny

Wprowadzenie do problemu / definicja

Masowa ekspozycja danych w środowiskach Supabase pokazała, jak groźne mogą być błędy konfiguracyjne w nowoczesnych platformach backendowych. W tym przypadku problem nie wynikał z pojedynczej luki w samym silniku PostgreSQL, ale z nieprawidłowego wdrożenia mechanizmów kontroli dostępu, w szczególności zasad Row Level Security, nadanych uprawnień oraz sposobu wykorzystania kluczy API.

Supabase upraszcza budowę aplikacji webowych i mobilnych, oferując gotowe API, autoryzację i warstwę danych. Jednocześnie odpowiedzialność za poprawne zabezpieczenie tabel, widoków i ról pozostaje po stronie twórców aplikacji. To właśnie na tym etapie doszło do szeregu błędów, które przełożyły się na realne ryzyko ujawnienia wrażliwych informacji.

W skrócie

Badacze bezpieczeństwa wykryli 16 326 baz Supabase, w których publicznie dostępne tabele pozwalały na odczyt danych. W wielu przypadkach schematy wskazywały na obecność danych osobowych, a część instancji ujawniała także hasła oraz tokeny uwierzytelniające.

Ekspozycja objęła tysiące środowisk w różnych branżach i regionach.
Problem wynikał głównie z błędnej konfiguracji RLS i nadmiernych uprawnień.
W niektórych przypadkach ujawniono rekordy klientów, wiadomości prywatne, dane kontaktowe i informacje o płatnościach.
Szczególnie niebezpieczne były przypadki przechowywania haseł jawnym tekstem oraz udostępnienia tokenów dostępowych.

Kontekst / historia

Popularność platform typu backend-as-a-service znacząco wzrosła wraz z zapotrzebowaniem na szybkie wdrażanie aplikacji. Supabase stał się jednym z najchętniej wybieranych rozwiązań dzięki prostocie integracji z PostgreSQL oraz szerokiemu zestawowi funkcji dla deweloperów.

Ten model pracy przyspiesza development, ale jednocześnie zwiększa ryzyko pominięcia krytycznych ustawień bezpieczeństwa. W środowiskach tworzonych pod presją czasu, a często także z użyciem narzędzi AI wspierających generowanie kodu, konfiguracja dostępu do danych bywa traktowana jako etap wtórny. Efektem mogą być wdrożenia produkcyjne z domyślnymi lub niekompletnymi zabezpieczeniami.

Opisywany przypadek pokazuje, że problem ma charakter systemowy. Nie dotyczy jednej organizacji ani pojedynczej kampanii ataków, lecz całego wzorca błędów konfiguracyjnych obecnych w aplikacjach wykorzystujących nowoczesne platformy BaaS.

Analiza techniczna

Podstawą bezpieczeństwa w Supabase jest właściwe połączenie uprawnień PostgreSQL, ról takich jak anon, authenticated i service_role, a także polityk Row Level Security. Sama ekspozycja tabeli przez API nie musi być zagrożeniem, o ile dostęp jest skutecznie ograniczony grantami i regułami RLS.

Problem pojawia się wtedy, gdy tabela znajduje się w schemacie dostępnym przez API, a jednocześnie rola publiczna ma możliwość odczytu lub modyfikacji danych. Jeśli RLS nie zostało włączone albo polityki są zbyt szerokie, publiczny klucz aplikacji może wystarczyć do wykonywania zapytań do informacji, które powinny być chronione.

Typowy scenariusz błędnej konfiguracji obejmował kilka elementów jednocześnie:

tabele zostały wystawione przez Data API,
rola publiczna otrzymała zbyt szerokie uprawnienia,
RLS nie było aktywne lub nie wymuszało ograniczeń,
klucze publikowalne były traktowane błędnie jako samodzielny mechanizm ochrony.

Z perspektywy technicznej jest to klasyczny przykład luki logicznej, a nie błędu pamięci czy podatności w oprogramowaniu. Oznacza to, że skuteczna ochrona wymaga nie tylko aktualizacji platformy, ale przede wszystkim poprawnego projektu autoryzacji, testów polityk dostępu oraz regularnego audytu konfiguracji.

Konsekwencje / ryzyko

Skutki ekspozycji takich danych mogą być bardzo poważne zarówno dla użytkowników końcowych, jak i operatorów aplikacji. Ujawnienie danych osobowych, haseł, tokenów sesyjnych czy informacji transakcyjnych tworzy warunki do dalszych nadużyć i kolejnych etapów kompromitacji.

przejęcie kont użytkowników,
ataki credential stuffing i password reuse,
kradzież tożsamości i nadużycia finansowe,
kompromitacja zintegrowanych usług przez ujawnione tokeny API,
obowiązki notyfikacyjne związane z naruszeniem ochrony danych,
straty reputacyjne oraz ryzyko sankcji regulacyjnych.

Szczególnie alarmujące są przypadki, w których hasła przechowywano w postaci jawnej. Taki błąd nie tylko zwiększa skalę incydentu, ale też podnosi prawdopodobieństwo wtórnych ataków na inne usługi, jeśli użytkownicy stosowali te same dane logowania w wielu miejscach.

Rekomendacje

Organizacje korzystające z Supabase powinny potraktować ten incydent jako sygnał do pilnego przeglądu konfiguracji bezpieczeństwa. Kluczowe działania obejmują zarówno szybkie ograniczenie ryzyka, jak i wdrożenie długofalowych mechanizmów kontrolnych.

zweryfikować, które tabele i widoki są udostępnione przez API,
włączyć RLS dla wszystkich obiektów dostępnych z poziomu aplikacji,
przejrzeć granty dla ról anon i authenticated,
usunąć zbędne uprawnienia odczytu i zapisu,
upewnić się, że klucze service_role nie trafiają do kodu klienckiego,
przeprowadzić rotację kluczy, tokenów i sekretów w razie podejrzenia ekspozycji,
sprawdzić funkcje SECURITY DEFINER oraz niestandardowe endpointy,
testować polityki RLS przed wdrożeniem na produkcję,
wdrożyć monitoring zapytań i alertowanie na nietypowy odczyt danych,
usunąć lub odpowiednio zabezpieczyć hasła i inne dane przechowywane w postaci jawnej.

Dodatkowo warto rozszerzyć pipeline CI/CD o automatyczne testy polityk bazy danych, walidację zmian uprawnień oraz checklisty bezpieczeństwa przed publikacją. W zespołach korzystających z narzędzi AI do przyspieszania developmentu szczególnie ważny pozostaje ręczny przegląd konfiguracji przed uruchomieniem środowiska produkcyjnego.

Podsumowanie

Przypadek ponad 16 tysięcy błędnie skonfigurowanych baz Supabase pokazuje, że nowoczesne platformy backendowe nie eliminują odpowiedzialności za bezpieczeństwo danych. Nawet jeśli infrastruktura jest zarządzana przez dostawcę, błędny model uprawnień i źle wdrożone zasady RLS mogą doprowadzić do masowego ujawnienia informacji.

Dla zespołów bezpieczeństwa i deweloperów to wyraźne ostrzeżenie: bezpieczeństwo BaaS należy traktować tak samo poważnie jak ochronę klasycznej infrastruktury produkcyjnej. Ostatecznie o poziomie ochrony decydują nie tylko możliwości platformy, lecz także jakość konfiguracji, testów i stałego audytu.