Privilegierter Schlüssel im Frontend
Service-Role- und Secret-Schlüssel umgehen RLS und dürfen nie den Browser erreichen.
Supabase-Sicherheitsprüfungen
Die tatsächlich erreichbare Supabase-Grenze prüfen
Vor der Verifizierung des Domain-Eigentums trennt BoringSec öffentliche Client-Schlüssel von privilegierten Secrets und führt begrenzte Nur-Lese-Probes aus. Die Verifizierung schaltet nur Injection, XSS, Ports sowie die externen Engines Nuclei, OWASP ZAP und Medusa frei.
Nach Änderungen an Richtlinien, Storage, Authentifizierung oder Umgebung und vor echten Kundendaten ausführen.
Scannen Sie nur eigene oder ausdrücklich freigegebene Systeme. Tiefen-Engines erfordern eine bestätigte Autorisierung und können für ein Ziel nicht verfügbar sein.
Bericht / BeispielbefundBeispiel
Kritisch
Beispielhafte Berichtsstruktur
Anonyme Anfrage kann Tabellenzeilen lesen
- Nachweis
- Eine begrenzte Leseanfrage mit öffentlichem Kontext lieferte Daten. Der Nachweis wird minimiert.
- Bedeutung
- Der beobachtete Pfad weist auf fehlendes oder zu breites RLS hin.
- Beheben und prüfen
- RLS aktivieren, minimale Rechte anwenden, Offenlegung prüfen und verifizieren.
Dieser Befund ist nur ein Beispiel und kein Ergebnis für Ihre Anwendung. Live-Berichte zeigen Scanner, Nachweisstatus und Abdeckungsgrenzen des tatsächlichen Ziels.
Typische Risikopfade
Was genauer geprüft werden sollte
Dies sind für Supabase-Projekte relevante Risikomuster, keine Behauptungen über jedes Projekt. Ein Befund entsteht nur mit Scanner-Nachweis.
Anonymer Zeilenzugriff
Fehlende oder breite Richtlinien können Daten über die öffentliche API freigeben.
Öffentlicher oder aufzählbarer Storage
Bucket- und Objektrichtlinien können nicht verlinkte Dateien offenlegen.
Ehrliche Abdeckung
Was jede Scan-Oberfläche belegen kann
URL, verbundener Quellcode und autorisierte Tiefen-Engines beantworten unterschiedliche Fragen. BoringSec trennt die Quellen und zeigt teilweise, blockierte oder nicht verfügbare Zustände.
Öffentliche Methodik lesen (auf Englisch)Projekt- und Schlüsselklassifizierung
Erkennt im ersten Bericht unterstützte URLs und trennt öffentliche von privilegierten Schlüsselformaten.
Begrenzte Tabellen-Probes
Nutzt vor der Eigentumsprüfung gedeckelte Leseanfragen und meldet geschützt, verifizierte Exposition oder nicht schlüssig.
Storage-Status
Prüft begrenztes Bucket-Listing ohne Objekte hochzuladen, zu ändern oder zu löschen.
Explizite Unsicherheit
Fehler, Limits und Ablehnungen reduzieren die Abdeckung statt einen Pass zu erzeugen.
Von der Beobachtung zur Verifizierung
Ein Bericht für den nächsten Schritt
- 01
Beobachten
Öffentliche Antworten prüfen und geeignete Hintergrund-Engines starten.
- 02
Nachweise prüfen
Sehen Sie, was welcher Scanner mit welcher Sicherheit beobachtet hat.
- 03
Im Kontext beheben
Nutzen Sie einen konkreten Lösungsweg und den relevanten Supabase RLS-Kontext.
- 04
Erneut testen
Starten Sie eine neue Bewertung. Monitoring erkennt spätere Regressionen.
Fragen vor dem Scan
Ist ein Supabase-Anon-Key ein geleaktes Secret?
Nein. Öffentliche Client-Schlüssel sind vorgesehen. RLS und Storage-Richtlinien bilden die Grenze.
Verändert der Scan die Datenbank?
Nein. Probes sind begrenzt und nur lesend. Sie fügen nichts ein, ändern und löschen nichts.
Kann er alle RLS-Richtlinien beweisen?
Nein. Nur beobachtete Pfade werden belegt. Authentifizierte Rollen benötigen autorisierten Kontext.
Belegt ein sauberes Ergebnis Supabase-Sicherheit?
Nein. Teilweise, blockierte und nicht verfügbare Abdeckung bleibt sichtbar.
Bereitgestellte Anwendung prüfen und jede Korrektur verifizieren
Beginnen Sie mit der öffentlichen URL. Quellcode oder authentifizierten Kontext fügen Sie nur bei Bedarf hinzu.
Sicherheitsscan starten