Sie haben Ihre Anwendung einem AI-Agenten beschrieben, zugesehen, wie das Interface in Sekunden gerendert wurde, und sich erfolgreich in Ihr neues Dashboard eingeloggt. Es fühlt sich wie ein riesiger Erfolg an. Sie laden Ihre ersten zehn Kunden ein, und alles sieht sauber aus. Doch hinter den schönen React-Komponenten und flüssigen Tailwind-Animationen könnte ein stilles Desaster warten.
Ein Client-Portal zu bauen ist grundlegend anders, als ein öffentliches Verzeichnis oder eine einfache Web-App zu erstellen. In einem Client-Portal ist die Datenisolation das einzige Feature, auf das es wirklich ankommt. Wenn ein Kunde Zugriff auf seine Rechnungen hat, darf er niemals die Rechnungen eines anderen Kunden sehen können.
Viele Builder nutzen AI-Code-Generatoren für das Grundgerüst dieser Portale und verlassen sich darauf, dass die AI Backends wie Supabase konfiguriert. Doch sich auf AI zu verlassen, um Row-Level Security (RLS) Policies zu schreiben, ist eine Abkürzung, die oft zu Datenlecks führt.
Hier erfahren Sie, warum AI-generierte Datenbank-Sicherheit fragil ist und warum visuelle Berechtigungsschemata ein zuverlässigerer Weg für Client-Portale sind.
Die Illusion der Frontend-Sicherheit
Wenn Sie mit AI-Assistenten bauen, neigen diese dazu, Code zu schreiben, der visuelles Feedback priorisiert. Die AI blendet einen Button aus, wenn der Nutzer kein Administrator ist, oder verbirgt eine Liste von Datensätzen, wenn die E-Mail des Nutzers nicht mit dem Datensatz übereinstimmt.
Das ist Frontend-Sicherheit - und sie ist für sich allein genommen völlig nutzlos.
Jeder mit einem Browser kann die Entwicklertools öffnen, auf den Netzwerk-Tab klicken und die eingehenden JSON-Payloads inspizieren. Wenn Ihre Anwendung alle Kundendaten aus der Datenbank abruft und diese erst im Frontend mit React oder Vue filtert, sind Ihre Daten bereits geleakt. Ein Angreifer muss Ihren Server nicht hacken - er muss nur F12 drücken, um die Rohdaten zu sehen, die Ihr Frontend-Code eigentlich verbergen wollte.
Um ein sicheres Portal zu bauen, müssen Sie die Daten auf Datenbankebene filtern, bevor sie überhaupt über das Netzwerk übertragen werden. Wenn ein Kunde eine Projektliste anfordert, muss die Datenbank-Engine die Session prüfen, die Identität verifizieren und nur die passenden Zeilen zurückgeben.
Bei Projekten, die auf Supabase basieren, hängt diese Datenbank-Sicherheit vollständig von der PostgreSQL Row-Level Security (RLS) ab.
Die Schwachstellen von KI-generiertem Supabase RLS
Supabase ist eine hervorragende Backend-Wahl für benutzerdefinierte Apps, verlagert die Sicherheitslast jedoch auf die Datenbankkonfiguration. Die Einrichtung von RLS erfordert das Schreiben präziser PostgreSQL-Policies mittels SQL.
Wenn Sie einen KI-Builder damit beauftragen, bauen Sie mehrere Fehlerquellen ein.
1. Context Window Drift und Beziehungs-Komplexität
Eine einfache RLS-Policy ist leicht zu schreiben. Wenn ein Benutzer eine Zeile besitzt, darf er sie lesen. Sie schreiben eine Regel, die prüft, ob auth.uid() = user_id ist.
Aber Kundenportale sind selten so simpel. Meist gibt es Organisationen, Teams, externe Auftragnehmer und verschiedene Rollen. Ein Projekt gehört vielleicht zu einer Organisation, und ein Benutzer ist Mitglied dieser Organisation mit einer spezifischen Rolle. Um zu prüfen, ob ein Benutzer einen Projektdatensatz lesen darf, muss die Datenbank eine Verknüpfungstabelle abfragen.
Je mehr Ihr Datenbank-Schema wächst, desto besser muss die KI diese Beziehungen im Blick behalten. Sobald Sie die KI für ein neues Feature prompten, kann ein sogenannter Context Window Drift auftreten. Die KI schreibt dann möglicherweise eine neue Abfrage, die die bestehende RLS-Logik umgeht oder die Policy vereinfacht, nur damit der Code läuft - und öffnet damit den Zugang für unbefugte Nutzer.
2. Stille Fehler in der SQL-Logik
PostgreSQL-Policies schlagen still fehl. Wenn Sie eine fehlerhafte Policy schreiben, stürzt PostgreSQL Ihre App nicht ab. Sie blockiert entweder den gesamten Zugriff oder - bei schlechter Konfiguration - lässt jeden die Daten lesen.
KI-Modelle machen oft subtile Fehler bei SQL-Nullwerten oder der booleschen Logik. Zum Beispiel eine Policy wie diese:
create policy "Users can view company data" on companies
for select using (
auth.uid() in (select user_id from members where company_id = id)
or public_access = true
);Wenn die Datenbank-Engine public_access als null auswertet oder die Unterabfrage unerwartet null zurückgibt, könnte die Policy für alle authentifizierten Nutzer als “wahr” gewertet werden. Eine KI generiert diesen Code oft, weil er syntaktisch korrekt aussieht, aber es fehlt die für echte Produktionsumgebungen notwendige Behandlung von Edge-Cases.
3. Die Testlücke
Professionelle Entwickler schreiben nicht einfach nur RLS-Policies; sie schreiben Test-Suites, um diese zu verifizieren. Sie nutzen Tools wie pgTAP, um verschiedene Benutzersessions zu simulieren und sicherzustellen, dass ein Kunde nicht die Daten eines anderen Kunden abfragen kann.
KI-Codegeneratoren schreiben diese Tests nicht, außer Sie fordern sie explizit dazu auf. Und selbst dann ist das Ausführen von Sicherheits-Tests auf Datenbankebene in einer KI-generierten Umgebung komplex. Ohne automatisierte Test-Suites raten Sie nur, ob Ihre Policies sicher sind. Sie merken erst, dass sie defekt sind, wenn ein Kunde anruft und fragt, warum er das Dashboard einer anderen Firma sehen kann.
Visuelle Berechtigungs-Schemata: die No-Code-Alternative
Wenn Sie keinen PostgreSQL-Code auditieren oder Test-Suites verwalten wollen, benötigen Sie ein anderes Sicherheitsmodell. Visuelle Berechtigungs-Schemata, wie sie in Softr verwendet werden, ersetzen benutzerdefinierten Datenbank-Code durch strukturierte, plattformseitig erzwungene Regeln.
Anstatt SQL-Statements zum Filtern von Zeilen zu schreiben, konfigurieren Sie Ihre Zugriffsregeln über ein visuelles Einstellungs-Panel.
Visuelles Mapping vs. SQL-Scripting
Während traditionelle Setups das Schreiben eigener Datenbank-Policies erfordern, setzen moderne Builder auf visuelle Einstellungen. In Softr definieren Sie Benutzergruppen basierend auf Datenbank-Attributen. Sie können zum Beispiel eine Gruppe “Client Portal Users” erstellen, bei der die Firmen-ID mit der Firmen-ID des angemeldeten Benutzers übereinstimmt.
Sobald diese definiert sind, wenden Sie die Gruppen direkt auf Seiten, Blöcke und Aktionen an. Die Plattform übernimmt das Backend-Routing und die Datenbankabfragen automatisch. Der Frontend-Block erhält nicht den vollständigen Datensatz; stattdessen filtert der Server die Datenquelle, bevor der Block gerendert wird.
Nativ sichere Datenbanken
Wenn Sie Softr Databases als native Datenschicht nutzen, ist die Row-Level Security von Anfang an in die Verbindung integriert. Sie schreiben keine Sicherheitsregeln direkt in den Datenbanktabellen - es gibt keinen generierten SQL-Code zum Auditieren, keine Migrations-Scripts und keine Policies, die gewartet werden müssen. Die Integrationsschicht schränkt den Abgriff standardmäßig ein, sodass es keinen generierten Code gibt, der driften, kaputtgehen oder nach einer Schemaänderung versehentlich Datensätze exponieren kann.
Wenn eine Benutzergruppe nur berechtigt ist, Datensätze mit dem Status “Aktiv” zu lesen, bei denen das Kundenfeld mit ihrem Konto übereinstimmt, erzwingt die Interface-Engine diesen Filter auf Abfrageebene. Der Kunde kann die API-Anfrage nicht manipulieren, um inaktive Datensätze oder Zeilen anderer Kunden abzurufen, da der Backend-Server unbefugte Parameter ignoriert.
Softr verbindet sich zudem mit über 17 externen Quellen - darunter Airtable und Google Sheets - falls Sie Daten einbinden möchten, die Sie bereits anderweitig verwalten. Die gleichen visuellen Regeln für Benutzergruppen gelten unabhängig davon, wo die Daten liegen.
Der Wartungsaufwand von generiertem Code
Der Bau eines Kundenportals ist kein einmaliges Ereignis. Ihre Geschäftsregeln werden sich ändern. Sie werden neue Kundenstufen hinzufügen, verschachtelte Projektstrukturen einführen oder die Art und Weise ändern, wie Administratoren eingereichte Dokumente prüfen.
In einer Anwendung mit generiertem Code, die mit Tools wie Bolt oder Lovable erstellt wurde, erfordert jede Layout-Änderung oder Beziehungs-Aktualisierung ein Refactoring des Datenbank-Schemas und ein Umschreiben Ihrer Sicherheits-Policies. Sie verlassen sich darauf, dass die KI:
- Die gesamte Codebasis liest, um das bestehende Schema zu verstehen.
- Ein Migrations-Script generiert, ohne bestehende Daten zu beschädigen.
- Die RLS-Regeln umschreibt, um die neuen Beziehungen zu berücksichtigen.
- Das React-Frontend aktualisiert, um die korrekten Header und Token zu übergeben.
Das ist das “Day Two”-Problem. Ein einziger Prompt kann eine zuvor funktionierende Sicherheits-Policy zerstören, und Sie merken es vielleicht erst, wenn der Code bereits in der Produktion ist.
Mit Softr nehmen Sie diese Änderungen vor, ohne eine Codebasis zu berühren. Sie können den AI Co-Builder nutzen, um die gewünschte Änderung zu beschreiben - “füge eine Manager-Benutzergruppe hinzu, die Projektebene-Einreichungen genehmigen kann” - und er aktualisiert die Benutzergruppen, Seiten und Berechtigungen gleichzeitig. Alternativ können Sie die Änderung manuell im Einstellungs-Panel vornehmen. In jedem Fall gibt es danach keinen generierten SQL-Code zu prüfen und kein Risiko, dass eine Regression der Sicherheits-Policy unbemerkt in die Produktion rutscht.
Sicherheits-Best-Practices für Ihr Kundenportal
Wenn Sie ein Portal bauen, das sensible Geschäftsdaten verarbeitet, beachten Sie diese Richtlinien:
Verlassen Sie sich nicht auf Frontend-Filter
Gehen Sie niemals davon aus, dass Daten sicher sind, nur weil sie im UI ausgeblendet werden. Stellen Sie immer sicher, dass Ihre Backend-API oder Datenquelle die Daten filtert, bevor sie gesendet werden. Wenn Ihre Plattform keine sichere Backend-Filterung unterstützt, nutzen Sie diese nicht für Kundenportale.
Halten Sie Benutzerrollen einfach
Vermeiden Sie übermäßig komplexe Berechtigungshierarchien. Wenn Ihre Berechtigungen zu kompliziert sind, als dass ein Mensch sie leicht prüfen könnte, wird auch eine KI Schwierigkeiten haben, sie korrekt zu schreiben. Bleiben Sie bei klaren, unterschiedlichen Benutzergruppen wie Admins, Managern und Kunden.
Wählen Sie strukturierte Tools für operative Software
KI-Codegeneratoren sind großartig für die Validierung, das Prototyping und den Bau benutzerdefinierter Consumer-SaaS-Interfaces. Aber wenn Ihre Hauptanforderungen operative Sicherheit, Datenisolation und langfristige Stabilität sind, ist eine strukturierte No-Code-Plattform die sicherere Wahl.
Indem Sie eine Plattform nutzen, die Sicherheitskonfigurationen vom Layout-Code trennt, stellen Sie sicher, dass Styling-Updates niemals versehentlich Ihre Datenbank dem öffentlichen Internet aussetzen. Sie erhalten ein sicheres, professionelles Portal auf einem stabilen Fundament und können sich auf Ihre Kunden konzentrieren, statt Datenbank-Policies zu debuggen.