Auswirkungen
Angreifer können die Anwendungslogik umgehen, um Datensätze in der Datenbank zu lesen, zu aktualisieren oder zu löschen, wenn die Zeilenebenensicherheit (RLS) nicht ordnungsgemäß durchgesetzt wird ([S1]). Dies führt häufig dazu, dass personenbezogene Daten (PII) oder sensible Anwendungsdaten Benutzern offengelegt werden, die nur Zugriff auf den öffentlichen, anonymen API-Schlüssel haben.
Grundursache
Supabase verwendet Postgres Row Level Security, um den Datenzugriff auf Datenbankebene zu verwalten, was für die Sicherung von Daten von grundlegender Bedeutung ist. [S1]. In einer Next.js-Umgebung müssen Entwickler einen Supabase-Client erstellen, der Cookies und Sitzungen korrekt verarbeitet, um die Sicherheit beim serverseitigen Rendern von [S2] aufrechtzuerhalten. Schwachstellen treten typischerweise auf, wenn:
- Tabellen werden ohne aktiviertes RLS erstellt, wodurch sie über den öffentlichen anonymen Schlüssel [S1] zugänglich sind.
- Der Supabase-Client ist in Next.js falsch konfiguriert und kann Benutzerauthentifizierungstoken nicht ordnungsgemäß an die Datenbank [S2] übergeben.
- Entwickler verwenden versehentlich den Schlüssel
service_roleim clientseitigen Code, der alle RLS-Richtlinien [S1] umgeht.
Konkrete Korrekturen
- RLS aktivieren: Stellen Sie sicher, dass die Zeilenebenensicherheit für jede Tabelle in Ihrer Supabase-Datenbank [S1] aktiviert ist.
- Richtlinien definieren: Erstellen Sie spezifische Postgres-Richtlinien für die Vorgänge
SELECT,INSERT,UPDATEundDELETE, um den Zugriff basierend auf der UID [S1] des Benutzers einzuschränken. - SSR-Clients verwenden: Implementieren Sie das Paket
@supabase/ssr, um Clients in Next.js zu erstellen, die die serverseitige Authentifizierung und Sitzungspersistenz [S2] korrekt verwalten.
Wie FixVibe darauf testet
FixVibe deckt dies bereits durch Deployed-App- und Repo-Checks ab. Das passive baas.supabase-rls-Modul erkennt Supabase-URL- und Anon-Key-Paare aus JavaScript-Bundles gleichen Ursprungs, fragt PostgREST nach öffentlichen Tabellenmetadaten und führt begrenzte schreibgeschützte Auswahlen durch, um die Offenlegung anonymer Daten zu bestätigen, ohne Kundendaten zu verändern. Repo-Scans führen außerdem repo.supabase.missing-rls aus, um SQL-Migrationen zu kennzeichnen, die öffentliche Tabellen ohne ENABLE ROW LEVEL SECURITY erstellen, und geheime Scans suchen nach Offenlegung von Dienstrollenschlüsseln, bevor diese den Browser erreichen.
