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
Przed weryfikacją własności domeny BoringSec odróżnia klucze publiczne od uprzywilejowanych sekretów i uruchamia ograniczone próby tylko do odczytu. Weryfikacja odblokowuje wyłącznie Injection, XSS, Ports oraz zewnętrzne silniki Nuclei, OWASP ZAP i Medusa.
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
W pierwszym raporcie wykrywa obsługiwane URL i rozróżnia klucze publiczne od uprzywilejowanych formatów.
Ograniczone próby tabel
Przed weryfikacją własności używa odczytów z limitem i raportuje stan chroniony, potwierdzoną ekspozycję lub wynik niejednoznaczny.
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