Uprzywilejowany klucz we frontendzie
Klucze service-role i secret omijają RLS i nie mogą trafić do przeglądarki.
Kontrole bezpieczeństwa Supabase
Sprawdź granicę Supabase faktycznie dostępną dla użytkowników
BoringSec odróżnia publiczne klucze klienta od uprzywilejowanych sekretów i stosuje ograniczone próby tylko do odczytu, gdy projekt można zweryfikować.
Użyj po zmianach polityk, storage, uwierzytelniania lub środowiska i przed udostępnieniem prawdziwych danych.
Skanuj wyłącznie własne systemy lub te, na które masz zgodę. Głębokie silniki wymagają potwierdzonej autoryzacji i mogą być niedostępne.
raport / przykładowe znaleziskoPrzykład
Krytyczne
Przykładowa struktura raportu
Anonimowe żądanie może czytać wiersze
- Dowód
- Ograniczony odczyt w publicznym kontekście zwrócił dane; zapisany dowód jest minimalizowany.
- Co to oznacza
- Zaobserwowana ścieżka wskazuje brak lub zbyt szerokie RLS.
- Napraw i zweryfikuj
- Włącz RLS, zastosuj minimalne uprawnienia, oceń ujawnienie i zweryfikuj.
To przykładowe znalezisko, a nie wynik Twojej aplikacji. Raporty na żywo pokazują skaner, stan dowodów i ograniczenia pokrycia konkretnego celu.
Typowe ścieżki ryzyka
Co wymaga dokładniejszej analizy
To wzorce ryzyka istotne dla projektów Supabase, a nie twierdzenia o każdym projekcie. Znalezisko powstaje tylko wtedy, gdy skaner dostarczy dowód.
Anonimowy odczyt wierszy
Brakujące lub zbyt szerokie polityki mogą ujawnić dane przez publiczne API.
Publiczny lub wyliczalny storage
Polityki bucketów i obiektów mogą ujawnić pliki bez linków w interfejsie.
Uczciwe pokrycie
Co może potwierdzić każda powierzchnia skanowania
URL, połączony kod i autoryzowane głębokie silniki odpowiadają na różne pytania. BoringSec rozdziela źródła i pokazuje stany częściowe, zablokowane oraz niedostępne.
Przeczytaj publiczną metodologię (po angielsku)Klasyfikacja projektu i kluczy
Wykrywa obsługiwane URL i rozróżnia klucze publiczne od uprzywilejowanych formatów.
Ograniczone próby tabel
Używa odczytów z limitem i raportuje stan ograniczony, podatny, niezweryfikowany lub pominięty.
Stan storage
Sprawdza ograniczone listowanie bucketów bez wysyłania, zmiany ani usuwania obiektów.
Jawna niepewność
Błędy, limity i odrzucenia obniżają pokrycie zamiast tworzyć zaliczenie.
Od obserwacji do weryfikacji
Raport prowadzący do następnego działania
- 01
Obserwuj
Sprawdź publiczną odpowiedź i uruchom odpowiednie silniki w tle.
- 02
Zweryfikuj dowody
Zobacz, co zaobserwowano, który skaner to wykrył i z jaką pewnością.
- 03
Napraw w kontekście
Użyj konkretnej ścieżki naprawy i kontekstu odpowiedniego dla Supabase RLS.
- 04
Przetestuj ponownie
Uruchom nową ocenę; monitoring wykryje późniejsze regresje.
Pytania przed skanem
Czy klucz anon Supabase to ujawniony sekret?
Nie. Publiczne klucze klienta są oczekiwane; RLS i polityki storage tworzą granicę.
Czy skan modyfikuje bazę?
Nie. Próby są ograniczone i tylko do odczytu; niczego nie dodają, nie zmieniają ani nie usuwają.
Czy potwierdzi wszystkie polityki RLS?
Nie. Potwierdza tylko obserwowane ścieżki; role uwierzytelnione wymagają autoryzowanego kontekstu.
Czy czysty wynik dowodzi bezpieczeństwa Supabase?
Nie. Częściowe, zablokowane i niedostępne pokrycie pozostaje widoczne.
Sprawdź wdrożoną aplikację i zweryfikuj każdą poprawkę
Zacznij od publicznego URL. Kod lub uwierzytelniony kontekst dodaj tylko wtedy, gdy chcesz rozszerzyć pokrycie.
Uruchom skan bezpieczeństwa