Skaner błędnych konfiguracji BaaS: znajdź publiczne ścieżki danych przed użytkownikami

Dlaczego błędne konfiguracje BaaS mają powracający kształt

Każda platforma BaaS podąża za tą samą architekturą: zarządzany backend z cienkim SDK klienta, który komunikuje się z nim z przeglądarki. Klient po stronie przeglądarki potrzebuje jakichś poświadczeń — klucza anon, klucza publicznego, identyfikatora projektu Firebase — aby zidentyfikować się wobec backendu. Te poświadczenia są celowo publiczne; bezpieczeństwo architektury opiera się na tym, że kontrole dostępu na poziomie platformy (RLS, reguły, listy dozwolonych) wykonują swoją pracę.

Narzędzia kodowania AI budują na tej architekturze bez uwewnętrznienia warstwy kontroli platformy. Poprawnie podłączają SDK klienta, akceptują domyślne permisywne reguły platformy (które istnieją dla przyjazności samouczków) i wydają. Powracający kształt to: publiczne poświadczenia + permisywna reguła domyślna + brakujące nadpisanie = ujawnienie danych. Pięć klas błędnych konfiguracji poniżej to wszystkie warianty tego kształtu.

Pięć powracających klas błędnych konfiguracji

Pojawiają się u każdego dostawcy BaaS. Pełne skanowanie obejmuje wszystkie pięć u każdego używanego dostawcy:

Klasa 1: Niewłaściwy klucz w pakiecie przeglądarki

Przeglądarka wysyła klucz sekretny/admin (Supabase service_role, klucz prywatny Firebase Admin SDK, Clerk sk_*, sekret klienta Auth0) zamiast publicznego/anon odpowiednika. Przeglądarka staje się nieograniczonym klientem administratora. Pokryte przez kontrolę sekretów pakietu FixVibe.

Klasa 2: Warstwa kontroli dostępu wyłączona lub permisywna

RLS jest wyłączony, reguły Firebase to if true, lista callbacków Auth0 jest wieloznaczna. Poświadczenia w przeglądarce są poprawne — ale granica na poziomie platformy, która miała je ograniczać, nie wykonuje swojej pracy.

Klasa 3: Anonimowe odczyty wrażliwych zasobów

Anonimowo odczytywalne kolekcje Firestore, anonimowo wyświetlalne kosze magazynu Supabase, anonimowo dostępne API zarządzania Auth0. Skan pyta: „bez poświadczeń, co mogę odczytać?"

Klasa 4: Artefakty trybu testowego w produkcji

Klucze testowe (pk_test_*, sb_test_*) we wdrożeniu produkcyjnym; aplikacje Firebase dev-mode osiągalne z domeny live; aplikacje Auth0 testowego najemcy ze słabszymi ustawieniami niż produkcja. Skan porównuje klucze środowiska wykonawczego z oczekiwanymi prefiksami produkcyjnymi.

Klasa 5: Brak weryfikacji podpisu webhooka

Webhooki Clerk, webhooki Stripe, webhooki Supabase — wszystkie podpisują swoje ładunki. Handler, który nie weryfikuje podpisu, to prymityw zapisu do bazy danych dla każdego atakującego, który zgadnie URL. Wykryty przez kształt odpowiedzi — niepodpisane żądanie, które otrzymuje 200, oznacza, że weryfikacja jest pomijana.

Jak działa parasolowe skanowanie FixVibe BaaS

Faza BaaS FixVibe działa w trzech etapach, każdy produkujący odrębne znaleziska:

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. Etap 2 — sondy specyficzne dla dostawcy. Dla każdego wykrytego dostawcy skaner uruchamia kontrolę specyficzną dla dostawcy: baas.supabase-rls sondy PostgREST; baas.firebase-rules sondy Firestore + RTDB + Storage; baas.clerk-auth0 waliduje prefiks pakietowanych kluczy; kontrola sekretów pakietu waliduje, że nie wyciekły żadne poświadczenia poziomu usługi. Każda sonda działa niezależnie — znalezisko Supabase nie blokuje skanowania Firebase.
3. Etap 3 — korelacja międzydostawcza. Skaner odnosi znaleziska wzajemnie. Wyciekły klucz roli serwisowej Supabase obok brakującego RLS jest poważniejszy niż każde znalezisko osobno — raport to wyłania. Wielu dostawców tożsamości (Clerk + Auth0 + niestandardowe uwierzytelnianie) w tej samej aplikacji to strukturalne znalezisko oznaczone do przeglądu.

Każda sonda jest pasywna: co najwyżej jeden anonimowy odczyt na zasób, z zapisanym kształtem odpowiedzi, ale zawartość wierszy nigdy nie jest stronicowana ani przechowywana. Sondy zapisu i modyfikacji są zabezpieczone potwierdzoną własnością domeny — nigdy nie działają wobec niezweryfikowanych celów.

Co skaner znajduje na dostawcę

Każdy dostawca BaaS ma inną powierzchnię i inną strategię skanowania. Oto, co jest pokryte:

• Supabase: brakujący RLS na tabelach, anonimowo wyświetlalne kosze magazynu, wyciekły JWT service_role lub klucz sb_secret_* w pakiecie, ujawnione schematy przez anonimowe listowanie OpenAPI. Zobacz Skaner Supabase RLS i Lista kontrolna magazynu.
• Firebase: reguły if true w Firestore, Realtime Database i Cloud Storage; anonimowo wyświetlalne kosze Storage; brakujące wymuszanie App Check. Zobacz Skaner reguł Firebase i Wyjaśnienie reguły if-true.
• Clerk: pakietowane klucze sekretne sk_*, pk_test_* w produkcji, brakująca weryfikacja podpisu webhooka, wieloznaczne dozwolone pochodzenia. Zobacz Lista kontrolna Clerk.
• Auth0: pakietowane sekrety klienta, włączony grant Implicit, wieloznaczne URL callbacka / wylogowania, brakujące PKCE na SPA. Zobacz Lista kontrolna Auth0.

Jak skaner BaaS porównuje się do ogólnych narzędzi DAST i SAST

Skaner świadomy BaaS wykonuje specyficzną pracę, której inne narzędzia nie robią. Porównanie:

Uczciwy zakres: czego ten skaner nie zastępuje

Skaner DAST świadomy BaaS to ukierunkowane narzędzie, a nie pełny program bezpieczeństwa. Nie:

• Zastępuje SAST ani SCA. Analiza statyczna znajduje CVE zależności (Snyk, Semgrep) i luki na poziomie kodu (SonarQube), których skaner DAST nie może. Uruchom oba.
• Zastępuje ręczne testy penetracyjne. Ludzki pentester znajduje wady logiki biznesowej, przypadki brzegowe autoryzacji i połączone luki, których żaden skaner nie może. Zatrudnij pentestera przed dużym wydaniem lub audytem zgodności.
• Audyt Twojego kodu lub repozytorium pod kątem sekretów w historii git. Kontrola sekretów pakietu obejmuje to, co jest obecnie wdrożone, a nie to, co historycznie zostało zatwierdzone. Użyj git-secrets lub gitleaks dla higieny repozytorium.
• Pokrywa usługi backendu spoza BaaS. Jeśli Twoja aplikacja używa niestandardowego backendu (Express, Rails, Django, FastAPI), FixVibe skanuje jego powierzchnię HTTP, ale nie sondy bazy danych ani infrastruktury za nim. To terytorium ogólnego DAST + SAST.

Często zadawane pytania

Następne kroki

Uruchom bezpłatne skanowanie FixVibe wobec swojego produkcyjnego URL — kontrole fazy BaaS są dostarczane w każdym planie, w tym na bezpłatnym poziomie. Dla szczegółowych analiz specyficznych dla dostawcy poszczególne artykuły w tej sekcji szczegółowo obejmują każdego dostawcę: Supabase RLS, Ujawnienie klucza serwisowego Supabase, Magazyn Supabase, Reguły Firebase, Firebase if-true, Clerk i Auth0.