Nutzerrollen und Rechte: Wer darf was in deiner App?

Dein Prototyp hat einen Login. Jeder der sich registriert, kann alles: Aufträge erstellen, Einstellungen ändern, andere Nutzer sehen. Das war für die ersten 10 Tester okay. Aber jetzt willst du echte Kunden onboarden — und plötzlich wird es ein Problem.

Dein Praktikant sieht die gleichen Daten wie der Geschäftsführer. Ein normaler Nutzer kann Admin-Funktionen aufrufen. Und wenn jemand die URL einer internen Seite kennt, kommt er einfach rein — auch ohne Berechtigung.

Das ist kein Edge Case. Das ist der Normalzustand bei AI-gebauten Prototypen. Und es ist eines der ersten Dinge die ein professioneller Entwickler ändert.

Der Unterschied: Authentication vs. Autorisierung

Zwei Begriffe die oft verwechselt werden, aber grundlegend verschieden sind:

Authentication (Authentifizierung): Wer bist du? → Login mit E-Mail und Passwort. Der Beweis deiner Identität.

Autorisierung: Was darfst du? → Welche Seiten, Funktionen und Daten stehen dir zur Verfügung?

Die Analogie: Authentication ist der Ausweis am Eingang. Autorisierung ist die Zugangskarte die bestimmt, in welche Räume du darfst. Dein Prototyp hat den Ausweis — aber gibt jedem den Generalschlüssel.

AI Tools wie Lovable bauen zuverlässig Authentication (Supabase Auth). Autorisierung vergessen sie fast immer.

Die typischen Rollen in einer Web-App

Rolle 1: Admin (Geschäftsführer, Inhaber)

Kann alles: - Alle Daten sehen und bearbeiten - Nutzer einladen und verwalten - Einstellungen ändern - Reports und Statistiken einsehen - Rechnungen und Zahlungen verwalten

Typisch: 1–3 Personen pro Organisation.

Rolle 2: Manager (Teamleiter, Abteilungsleiter)

Kann vieles: - Daten des eigenen Teams sehen und bearbeiten - Aufgaben zuweisen - Reports für das eigene Team einsehen - Keine Nutzer verwalten, keine globalen Einstellungen

Typisch: 3–10 Personen pro Organisation.

Rolle 3: User (Mitarbeiter, Kunde)

Kann das Nötige: - Eigene Daten erstellen und bearbeiten - Zugewiesene Aufgaben sehen - Eigenes Profil verwalten - Keine fremden Daten, keine Admin-Funktionen

Typisch: Die meisten Nutzer.

Rolle 4: Viewer (Gast, externer Partner)

Kann wenig: - Bestimmte Daten ansehen - Nichts bearbeiten, nichts erstellen - Kein Zugriff auf interne Bereiche

Typisch: Externe Partner, Auditoren, Kunden die nur Status einsehen.

Was passiert ohne Rollen-System

Szenario 1: Datenschutz-Verstoß Nutzer A öffnet eine URL die eigentlich nur für Admins gedacht ist. Er sieht die E-Mails und Adressen aller Nutzer. Das ist ein DSGVO-Verstoß — meldepflichtig, potenziell teuer.

Szenario 2: Versehentliche Datenänderung Ein neuer Mitarbeiter ändert versehentlich die globalen Einstellungen. Alle Preise sind plötzlich falsch. Niemand weiß warum — und es gibt keinen Audit Trail.

Szenario 3: Vertrauensverlust Ein Kunde sieht die Daten eines anderen Kunden. Das Vertrauen ist zerstört — und der Kunde erzählt es weiter.

Alle drei Szenarien sind vermeidbar. Mit einem professionellen Rollen-System.

Wie Rollen technisch funktionieren

Level 1: Frontend-Schutz (was AI Tools machen)

Die AI versteckt Admin-Menüpunkte für normale Nutzer. Wenn du nicht Admin bist, siehst du den „Einstellungen”-Button nicht.

Problem: Das ist Kosmetik, keine Sicherheit. Wer die URL kennt (/admin/settings), kommt trotzdem rein. Im Browser-Code stehen alle Seiten — jeder mit F12 kann sie finden.

Level 2: Backend-Schutz (was der Profi macht)

Jede API-Anfrage prüft: Hat dieser Nutzer die Berechtigung für diese Aktion? Wenn nicht → Zugriff verweigert. Egal ob er die URL kennt.

Wie das funktioniert: 1. Nutzer loggt sich ein → bekommt eine Rolle (admin, manager, user, viewer) 2. Nutzer ruft eine Seite auf → Frontend zeigt nur relevante Elemente 3. Frontend fragt Daten von der API → API prüft die Rolle 4. Rolle berechtigt? → Daten werden geliefert 5. Rolle nicht berechtigt? → Fehlermeldung: „Keine Berechtigung”

Level 3: Datenbank-Schutz (die Königsklasse)

Row Level Security (RLS) in Supabase: Selbst wenn jemand direkt auf die Datenbank zugreift, sieht er nur die Daten die seiner Rolle entsprechen.

Beispiel-Policy: - Admin → Sieht alle Aufträge - Manager → Sieht Aufträge seines Teams - User → Sieht nur seine eigenen Aufträge - Viewer → Sieht zugewiesene Aufträge, kann nichts ändern

Ein professionelles Rollen-System nutzt alle drei Level gleichzeitig: Frontend verbirgt, Backend prüft, Datenbank erzwingt.

Was AI Tools können — und was nicht

Die AI baut die Oberfläche. Der Entwickler baut die Sicherheit dahinter.

Wie ein Entwickler Rollen implementiert

Schritt 1: Rollen-Feld in der Datenbank

Eine neue Spalte role in der Nutzer-Tabelle: admin, manager, user, viewer. Einfach, aber wirkungsvoll.

Schritt 2: RLS-Policies in Supabase

Für jede Tabelle eine Policy die bestimmt: Wer darf lesen, schreiben, ändern, löschen?

Schritt 3: API-Middleware

Jede API-Anfrage wird durch eine Berechtigungs-Prüfung geschickt. Falscher Rolle → Zugriff verweigert, bevor die Daten überhaupt abgefragt werden.

Schritt 4: Frontend-Anpassung

Navigation, Buttons und Seiten werden basierend auf der Rolle angezeigt oder versteckt. Aber nicht als einzige Schutzmaßnahme — nur als Komfort-Feature.

Schritt 5: Admin-Panel

Eine Seite für Admins um Nutzer zu verwalten: Rollen zuweisen, Nutzer einladen, Zugänge sperren.

Typischer Aufwand: 1–2 Wochen Entwicklerarbeit für ein solides Rollen-System.

Die häufigsten Rollen-Szenarien

SaaS-App (B2B)

Marktplatz

Internes Tool

FAQ: Häufig gestellte Fragen

Kann ich Rollen mit einem Prompt in Lovable einbauen?

Einfache Frontend-Rollen (Admin sieht mehr Menüpunkte): Ja. Echte Backend-Autorisierung mit RLS: Nein — das ist zu komplex für AI-Prompts und zu kritisch für die Sicherheit. Das macht der Entwickler.

Wie viele Rollen brauche ich?

Starte mit 2: Admin und User. Das deckt 80% der Fälle ab. Mehr Rollen nur wenn du echte Use Cases hast — nicht vorsorglich. Jede zusätzliche Rolle erhöht die Komplexität.

Was kostet ein professionelles Rollen-System?

Für ein einfaches System (Admin + User): 2.000–4.000 €. Für ein komplexes System (mehrere Rollen, Team-basierte Rechte, Audit Trail): 5.000–10.000 €. Beides als Teil der Gesamtprofessionalisierung.

Brauche ich Rollen schon im Prototyp?

Für die Validierungsphase: Nein. Alle deine 20 Tester sind quasi Admins — das ist okay. Sobald du zahlende Kunden hast oder unterschiedliche Nutzergruppen (Mitarbeiter + Kunden, Chef + Team): Ja, dann sind Rollen Pflicht.

Was ist ein Audit Trail und brauche ich einen?

Ein Audit Trail speichert wer wann was geändert hat. „Nutzer X hat am 15.03. um 14:30 den Status von Auftrag 47 auf ‘Erledigt’ gesetzt.” Für regulierte Branchen (Gesundheit, Finanzen) ist er Pflicht. Für andere Branchen: Ab 50+ Nutzern sinnvoll, davor optional.

Fazit: Rollen sind kein Luxus — sie sind DSGVO-Pflicht

Sobald verschiedene Menschen mit verschiedenen Berechtigungen auf deine App zugreifen, brauchst du ein Rollen-System. Nicht weil es schön wäre, sondern weil die DSGVO es vorschreibt: Personenbezogene Daten dürfen nur von berechtigten Personen eingesehen werden.

Die AI baut dir den Login. Der Entwickler baut dir die Zugangskontrolle. Zusammen entsteht ein System in dem jeder genau das sehen und tun kann, was er soll — nicht mehr und nicht weniger.

Deine App braucht professionelle Zugangskontrolle? Wir implementieren Nutzerrollen, RLS und ein Admin-Panel — sicher, skalierbar und DSGVO-konform.

Jetzt Rollen-System einrichten