Row Level Security & Grundschutz bei No-Code-Shops (Supabase-Basis)

Row Level Security als Grundschutz

No-Code-Backends wie Supabase nehmen viel Arbeit ab, die früher in der Hand lag: die Datenbank, die Authentifizierung, die Speicherung. Wer ein solches Backend nutzt, verantwortet aber weiterhin, wer auf welche Daten zugreifen darf. Das zentrale Mittel dafür heißt Row Level Security, kurz RLS.

RLS muss auf allen Tabellen aktiviert sein. Ohne RLS ist eine Tabelle über die Datenbank-API erreichbar, sobald ein Zugang besteht – und das bedeutet, dass jeder, der den öffentlichen Zugang nutzt, im Grunde alle Daten sieht, die in dieser Tabelle stehen. RLS dreht diese Voreinstellung um: Es ist standardmäßig alles gesperrt, und nur was ausdrücklich erlaubt wird, ist erreichbar.

Für einen Shop oder eine Anwendung heißt das in der Praxis: Öffentliches Lesen kann erlaubt sein, etwa wenn Produkte, Artikel oder Inhalte für alle Besucher sichtbar sein sollen. Schreiben, Ändern und Löschen darf aber nur für authentifizierte, berechtigte Nutzer möglich sein. Die Trennung zwischen „lesen darf jeder" und „ändern darf nur, wer eingeloggt und berechtigt ist" ist die Grundregel, auf der der Schutz aufbaut.

Anon-Key und Service-Role-Key

Supabase arbeitet mit zwei unterschiedlichen Schlüsseln, die klar zu trennen sind. Der öffentliche Anon-Key ist der Schlüssel, der im Frontend der Anwendung liegt. Er erlaubt den Zugriff auf die Daten, aber nur im Rahmen der Regeln, die RLS festlegt. Der Service-Role-Key dagegen umgeht RLS vollständig – er greift auf alle Daten zu, unabhängig von den definierten Regeln.

Das Frontend darf niemals den Service-Role-Key verwenden. Wer den Service-Role-Key im Frontend einbindet, hebt den gesamten Schutz auf, den RLS aufgebaut hat. Der Service-Role-Key gehört ausschließlich in den geschützten Bereich – etwa in eine serverseitige Funktion, die der Entwickler selbst kontrolliert, oder in einen administrativen Zugriff, der nicht über den Browser läuft. Im Browser hat ausschließlich der Anon-Key etwas zu suchen.

Diese Trennung ist nicht optional, sondern die Grundlage des gesamten Schutzes. Wer den Service-Role-Key im Frontend verwendet, weil es praktisch erscheint, alle Daten abzurufen, baut eine Sicherheitslücke ein, die sich später nicht durch Regeln schließen lässt – der Schlüssel selbst umgeht jede Regel.

Parametrisierte Abfragen gegen SQL-Injection

Die dritte Grundregel betrifft die Eingaben der Nutzer. Jede Eingabe – sei es ein Suchbegriff, ein Formularfeld, ein Filterwert – muss über parametrisierte Datenbank-Anfragen laufen, nie über zusammengesetzte SQL-Strings. Bei einer parametrisierten Abfrage wird der Wert als eigener Parameter übergeben, getrennt vom eigentlichen SQL-Text. Die Datenbank behandelt den Parameter strikt als Wert und nicht als Teil des Befehls.

Wer dagegen SQL-Strings zusammenbaut – etwa indem er einen eingegebenen Text direkt in eine Abfrage einsetzt – öffnet die Tür für SQL-Injection. Ein Angreifer kann über ein scheinbar harmloses Feld eigene Befehle einschleusen, die dann von der Datenbank ausgeführt werden. Die Folgen reichen vom Auslesen geschützter Daten bis zur Veränderung oder Löschung der gesamten Tabelle.

Die Parameterisierung ist kein zusätzlicher Aufwand, den man optional vornimmt, sondern die Art, wie Abfragen grundsätzlich aufgebaut werden sollten. Wer eine Suchfunktion, ein Filter oder ein Formular einrichtet, gibt die Werte als Parameter mit, nicht als Bestandteil des SQL-Texts. Das ist eine Frage des verwendeten Clients und der Art, wie Abfragen formuliert werden – die parametrisierte Form ist in den meisten Bibliotheken die natürliche Variante.

Die drei Regeln zusammen

Der Grundschutz bei No-Code-Backends besteht aus drei Regeln, die zusammenwirken. Erstens: RLS auf allen Tabellen, mit der klaren Trennung zwischen öffentlichem Lesen und authentifiziertem Schreiben. Zweitens: der Anon-Key im Frontend, der Service-Role-Key ausschließlich im geschützten Bereich. Drittens: parametrisierte Abfragen für alle Nutzereingaben, um SQL-Injection auszuschließen.

Wer eine dieser Regeln außer Acht lässt, öffnet eine Lücke, die die anderen beiden nicht schließen können. RLS allein nützt nichts, wenn der Service-Role-Key im Frontend liegt. Parameterisierung allein nützt nichts, wenn ohne RLS jede Tabelle frei lesbar ist. Erst das Zusammenwirken aller drei Regeln ergibt den Grundschutz, auf dem eine Anwendung verantwortbar betrieben werden kann.

Wer diese Grundregeln von Anfang an beachtet, baut ein No-Code-Backend auf, das die Bequemlichkeit der Plattform mit der Sicherheit verbindet, die der Betrieb sensibler Daten verlangt. Nachträglich nachzubessern ist möglich, aber mühsamer als die bewusste Entscheidung am Anfang.

Allgemeine Information, keine Rechtsberatung. Stand: 10. September 2026.