service_role-Client vertraut der Nutzer-ID aus der Anfrage
Prüfregel · RSC-SEC-140
- Sicherheit
- Schweregrad: Hoch
- CWE-639
- OWASP A01-2021
Findet Serverfunktionen (Edge Functions, API-Routen, Express & Co.), die mit dem service_role-Schlüssel auf Daten oder Konten zugreifen und den Datensatz über eine ID aus Body, URL oder Header wählen — ohne vorherige Prüfung mit getUser oder getClaims.
Warum das zählt
Das ist das häufigste Backend-Muster einer Lovable-App: Eine Edge Function baut einen Client mit `SUPABASE_SERVICE_ROLE_KEY`, liest `userId` aus dem Request-Body und löscht oder ändert damit Datensätze. Der Schlüssel umgeht Row Level Security vollständig — welche Zeilen betroffen sind, entscheidet allein, was der Aufrufer in den Body schreibt.
Von außen sieht das sauber aus: Die Tabellen sind per RLS geschützt, der Browser bekommt nichts heraus. Die Lücke liegt eine Ebene tiefer, in der Funktion, die die Policies absichtlich umgeht. Generische Code-Scanner kennen dieses Muster nicht als Vertrauensbruch, weil sie den Unterschied zwischen anon- und service_role-Schlüssel nicht kennen.
Fix: Den Token aus dem Authorization-Header mit `supabase.auth.getUser(token)` prüfen, ohne Nutzer mit 401 abbrechen und ausschließlich `user.id` verwenden. Wo die Funktion keine Sonderrechte braucht, einen nutzerbezogenen Client mit dem öffentlichen Schlüssel und dem weitergereichten Authorization-Header bauen — dann prüft RLS.
Prüfstufe
- Quellcode aus Source Maps
- Repo-Zugang (Deep-Scan)
So behebt ihr es
Die Identität mit supabase.auth.getUser(token) aus dem Authorization-Header bestimmen und nur diese ID verwenden; den service_role-Client nur dort einsetzen, wo es keinen Nutzerbezug gibt.