So fügst du deiner App rollenbasierte Zugriffskontrolle (RBAC) hinzu

Um rollenbasierte Zugriffskontrolle hinzuzufügen, gib jedem Nutzer eine oder mehrere Rollen (zum Beispiel Admin, Redakteur, Betrachter), lege fest, welche Aktionen jede Rolle ausführen darf, und prüfe diese Berechtigungen auf dem Server bei jeder Anfrage, nicht nur durch Verstecken von Buttons. Prüfe außerdem, dass der aufgerufene Datensatz zum Konto oder Team des Nutzers gehört. Beginne mit wenigen festen Rollen in deiner Datenbank und teste, indem du direkt versuchst, auf die Daten eines anderen Nutzers zuzugreifen.

Authentifizierung vs. Autorisierung

Zwei Begriffe, die gern verwechselt werden:

• Authentifizierung beantwortet Wer bist du? – die Anmeldung. Siehe wie du deiner App eine Anmeldung hinzufügst.
• Autorisierung beantwortet Was darfst du tun? – welche Seiten, Datensätze und Aktionen ein angemeldeter Nutzer erreichen kann.

RBAC ist die gängigste Form der Autorisierung. Das ist wichtig: Laut der OWASP Top 10:2025, der weit verbreiteten Liste der schwerwiegendsten Sicherheitsrisiken für Webanwendungen, steht Fehlende Zugriffskontrolle Stand September 2026 an Platz 1. Typische Fehler sind Nutzer, die Datensätze anderer lesen, indem sie eine ID in der URL ändern, oder normale Nutzer, die Admin-only-API-Routen aufrufen.

Ein Modell wählen

In der Praxis kombinieren die meisten Apps zwei Dinge: Rollen für die Art der Aktionen, die jemand ausführen darf, und Zugehörigkeit für die Datensätze, auf die er sie anwenden darf. „Redakteure dürfen Beiträge bearbeiten“ ist eine Rollenregel; „…Beiträge im eigenen Arbeitsbereich“ ist eine Zugehörigkeitsregel. Du brauchst beides.

Fang einfacher an, als du denkst. Admin, Mitglied und Betrachter decken erstaunlich viele Apps ab. Eine Rolle später aufzuteilen ist leichter, als zehn Rollen zu entwirren, die niemand versteht.

Rollen entwerfen, bevor du Code schreibst

Schreibe zuerst eine Berechtigungstabelle in einfacher Sprache. Sie dient gleichzeitig als Spezifikation für die KI und als Testplan:

Kläre auch die Grenzfälle: Darf der letzte Eigentümer das Team verlassen? Darf ein Admin den Eigentümer entfernen? Was sieht ein entfernter Nutzer?

Schritt für Schritt

1. Zuerst eine funktionierende Anmeldung

RBAC sitzt auf der Authentifizierung auf. Der Server muss zuverlässig wissen, wer jede Anfrage stellt, aus einer Sitzung oder einem geprüften Token, niemals aus einer Nutzer-ID, die der Browser im Anfragekörper mitschickt.

2. Rollen in der Datenbank speichern

Für eine App mit einem einzigen Team reicht eine Spalte role bei den Nutzern. Für Teams nutze eine Mitgliedstabelle:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Lass Nutzer ihre Rolle niemals über ein normales Profil-Update selbst setzen. Rollenänderungen laufen über einen eigenen, berechtigungsgeprüften Endpunkt.

3. Berechtigungen auf dem Server an einer Stelle prüfen

Schreibe eine zentrale Hilfsfunktion – etwa can(user, 'projects.delete', project) – und rufe sie in jeder API-Route, jeder Server-Aktion und jeder Hintergrundaufgabe auf, die Daten liest oder ändert. Eine zentrale Funktion lässt sich leichter prüfen und testen als Prüfungen, die im Code verstreut sind. Verweigere standardmäßig: Wenn keine Regel eine Aktion erlaubt, wird sie abgelehnt.

4. Jede Abfrage eingrenzen

Jede Abfrage nach Teamdaten sollte das Team einbeziehen: where organization_id = :currentOrg, nicht nur where id = :id. Genau das verhindert, dass jemand /projects/123 in /projects/124 ändert und das Projekt eines anderen Unternehmens sieht. Gib für Datensätze anderer Teams „nicht gefunden“ statt „verboten“ zurück, damit du nicht verrätst, dass sie existieren.

5. Datenbankseitigen Schutz ergänzen, wo er zählt

Postgres-Zeilenebenen-Sicherheit (Row-Level Security, RLS) lässt die Datenbank durchsetzen, welche Zeilen ein Nutzer sehen darf. Sie ist unverzichtbar, wenn der Browser direkt mit der Datenbank spricht (wie bei manchen gehosteten Backends), und sonst eine nützliche zweite Schicht für sensible Tabellen.

6. Rollen in der Oberfläche widerspiegeln

Blende jetzt aus oder deaktiviere, was Nutzer nicht tun können, damit die App nicht verwirrt. Das dient nur der Bedienbarkeit; die Prüfungen auf dem Server schützen tatsächlich.

7. Sensible Aktionen protokollieren

Halte fest, wer Rollen geändert, Daten gelöscht oder Datensätze exportiert hat, und wann. Ein Audit-Protokoll hilft bei Supportfragen und Vorfällen.

8. Wie ein Angreifer testen

Melde dich als jede Rolle an und probiere jede Aktion der Berechtigungstabelle aus. Dann versuche die Dinge, die nicht funktionieren dürfen: Admin-API-Routen als Betrachter aufrufen, IDs in URLs und Anfragen ändern, dich als letzten Eigentümer selbst entfernen. Automatisierte Tests für die Berechtigungstabelle lohnen sich, sobald die Regeln feststehen.

Prompts, die funktionieren

Füge rollenbasierte Zugriffskontrolle hinzu. Rollen pro Organisation: Eigentümer, Admin, Mitglied, Betrachter, gespeichert in einer Mitgliedstabelle. Die Berechtigungen stehen in dieser Tabelle: [deine Tabelle einfügen]. Erstelle eine serverseitige Hilfsfunktion can(user, action, resource), die standardmäßig verweigert, und verwende sie in jeder API-Route. Grenze jede Abfrage nach organization_id ein. Blende in der Oberfläche Aktionen aus, die der Nutzer nicht ausführen darf, verlasse dich aber für die Sicherheit niemals darauf.

Prüfe jede API-Route und jede Serverfunktion in dieser App. Liste für jede auf, welche Daten sie liest oder ändert, ob sie prüft, dass der Nutzer angemeldet ist, ob sie seine Rolle prüft und ob sie die Abfrage auf seine Organisation eingrenzt. Behebe alle fehlenden Prüfungen und zeige mir die Liste.

Füge eine Seite /admin hinzu, nur für Admins, auf der der Eigentümer die Rollen der Mitglieder ändern kann. Verhindere, dass der letzte Eigentümer entfernt oder herabgestuft wird, protokolliere jede Rollenänderung mit Urheber und Zeitpunkt, und stelle sicher, dass der Endpunkt für Rollenänderungen alle ablehnt, die keine Eigentümer sind.

Häufige Fehler

• Rollen nur im Frontend prüfen. Die API ist trotzdem für jeden offen, der sie aufruft.
• IDs aus dem Client vertrauen – eine userId oder role im Anfragekörper statt in der Sitzung.
• Nicht eingegrenzte Abfragen, die nur nach der Datensatz-ID suchen.
• Rollen auf Seiten geprüft, aber nicht auf API-Routen, bei Exporten, Datei-Downloads oder Webhooks.
• Admin anhand einer E-Mail-Adresse im Code fest verdrahtet (if email === 'ich@...'). Das wird leicht vergessen und ist schwer zu ändern.
• Zu viele Rollen zu früh, die niemand nach sechs Monaten erklären kann.
• Veraltete Sitzungen: Ein herabgestufter Nutzer behält Adminrechte, bis er sich abmeldet. Prüfe Rollen bei sensiblen Aktionen aus der Datenbank oder aktualisiere sie.

Checkliste für RBAC

• Berechtigungstabelle in einfacher Sprache geschrieben, Grenzfälle entschieden
• Der Server kennt den Nutzer aus der Sitzung, nie aus Anfragedaten
• Rollen liegen in der Datenbank; Nutzer können ihre eigene nicht ändern
• Eine zentrale Berechtigungsprüfung, standardmäßig verweigernd, in jeder Route verwendet
• Jede Abfrage ist auf die Organisation oder den Eigentümer des Nutzers eingegrenzt
• Zeilenebenen-Sicherheit, wo der Browser die Datenbank erreichen kann
• Die Oberfläche blendet aus, was Nutzer nicht tun können (nur zur Bedienbarkeit)
• Sensible Aktionen werden protokolliert
• Jede Rolle getestet, einschließlich direkter API-Aufrufe und geänderter IDs

Zugriffskontrolle ist ein Punkt auf einer längeren Liste; die Sicherheits-Checkliste für mit KI gebaute Apps deckt den Rest ab. Wenn du ein Werkzeug für deine eigenen Mitarbeiter baust, zeigt wie du ein internes Werkzeug baust, wo Rollen hineinpassen.

RBAC auf Mythex

Mythex bietet für die Nutzer deiner App kein eingebautes Anmelde- oder Rollensystem. Du wählst eine Authentifizierungsbibliothek oder einen Anbieter und beschreibst die Rollen; der Agent verdrahtet sie mit deinem Code und der Postgres-Datenbank des Projekts (eine Anmeldung zu deiner App hinzufügen). Die Workspace-Rollen von Mythex, etwa Eigentümer und Mitglied, bestimmen, wer deine Mythex-Projekte bearbeiten darf, nicht, wer die veröffentlichte App nutzen kann. Nutze den Planungsmodus, um die Berechtigungstabelle vor dem Bauen festzulegen, und verwende danach den Prüf-Prompt oben. Teste jede Rolle in der Vorschau, bevor du veröffentlichst. Die Sicherheits-Prompts in der Dokumentation sind eine nützliche Ergänzung.

Fragen