Hak
Zabezpieczenie projektu Supabase wymaga wielowarstwowego podejścia skupiającego się na zarządzaniu kluczami API, bezpieczeństwie bazy danych i uprawnieniach do przechowywania. [S1] Nieprawidłowo skonfigurowane zabezpieczenia na poziomie wiersza (RLS) lub ujawnione wrażliwe klucze mogą prowadzić do poważnych incydentów ujawnienia danych. [S2] [S3]
Co się zmieniło
Badanie to konsoliduje podstawowe mechanizmy kontroli bezpieczeństwa dla środowisk Supabase w oparciu o oficjalne wytyczne dotyczące architektury. [S1] Koncentruje się na przejściu od domyślnych konfiguracji programistycznych do postaw dostosowanych do produkcji, szczególnie w odniesieniu do mechanizmów kontroli dostępu. [S2] [S3]
Kogo to dotyczy
Dotyczy to aplikacji wykorzystujących Supabase jako backend-as-a-Service (BaaS), szczególnie te, które obsługują dane specyficzne dla użytkownika lub zasoby prywatne. [S2] Programiści, którzy dołączają klucz service_role do pakietów po stronie klienta lub nie włączają RLS, są narażeni na wysokie ryzyko. [S1]
Jak działa problem
Supabase wykorzystuje zabezpieczenia na poziomie wierszy PostgreSQL w celu ograniczenia dostępu do danych. [S2] Domyślnie, jeśli w tabeli nie włączono opcji RLS, każdy użytkownik posiadający klucz anon — który często jest publiczny — może uzyskać dostęp do wszystkich rekordów. [S1] Podobnie Supabase Pamięć masowa wymaga jawnych zasad określających, którzy użytkownicy lub role mogą wykonywać operacje na zasobnikach plików. [S3]
Co dostaje atakujący
Osoba atakująca posiadająca publiczny klucz API może wykorzystać brakujące tabele RLS do odczytu, modyfikacji lub usunięcia danych należących do innych użytkowników. [S1] [S2] Nieautoryzowany dostęp do zasobników pamięci może prowadzić do ujawnienia prywatnych plików użytkowników lub usunięcia krytycznych zasobów aplikacji. [S3]
Jak FixVibe to testuje
FixVibe uwzględnia to teraz w ramach kontroli Supabase. baas.supabase-security-checklist-backfill przegląda publiczne metadane zasobnika Supabase, ekspozycję anonimowych list obiektów, wrażliwe nazewnictwo zasobników i niepowiązane sygnały magazynu z publicznej granicy anon. Powiązane kontrole na żywo sprawdzają ekspozycję klucza roli usługi, postawę Supabase REST/RLS i migracje SQL repozytorium pod kątem brakującego RLS.
Co naprawić
Zawsze włączaj zabezpieczenia na poziomie wierszy w tabelach bazy danych i wdrażaj szczegółowe zasady dla uwierzytelnionych użytkowników. [S2] Upewnij się, że w kodzie po stronie klienta używany jest wyłącznie klucz „anon”, podczas gdy klucz „rola_usługi” pozostaje na serwerze. [S1] Skonfiguruj kontrolę dostępu do pamięci masowej, aby mieć pewność, że zasobniki plików są domyślnie prywatne, a dostęp jest przyznawany wyłącznie poprzez zdefiniowane zasady bezpieczeństwa. [S3]