Authentifizierung und Autorisierung in KI-generierten Apps: Warum ein Login nicht ausreicht

Eine KI-generierte App kann ein perfektes Login-System haben und dennoch verwundbar bleiben. Der Benutzer meldet sich über Google, GitHub, E-Mail/Passwort, Auth0, Supabase Auth oder Firebase Authentication an; die Sitzung wird erstellt; das Dashboard zeigt nur die vorgesehenen Schaltflächen an. Doch all das beweist nur eines: Die App weiß, wer der Benutzer ist. Es beweist nicht, was dieser Benutzer lesen, ändern, löschen, exportieren oder verwalten darf.

Das Risiko entsteht, wenn der von der KI generierte Code Authentifizierung und Autorisierung vermischt. Die Authentifizierung beantwortet die Frage „Wer bist du?“, während die Autorisierung die Frage beantwortet: „Was darfst du mit diesem Objekt, in diesem Mandanten, mit dieser Rolle, in diesem Workflow-Status tun?“. Bei Web-Apps, SaaS-Lösungen und internen Tools, die schnell mit KI erstellt wurden, ist dieser zweite Teil oft der schwächste.

Die entscheidende Prüfung vor dem Go-Live ist einfach zu beschreiben, aber schwer zu improvisieren: Ein authentifizierter Benutzer darf nur auf Daten, Dateien, Funktionen, Berichte, Bestellungen, Projekte, Arbeitsbereiche und Aktionen zugreifen, die ihm tatsächlich gehören. Wenn es ausreicht, eine ID in einer Anfrage zu ändern, um an die Daten anderer zu gelangen, schützt das Login das Produkt nicht.

[Callforaction-WAPT]

AuthN und AuthZ: Die Unterscheidung, die über die Sicherheit entscheidet

AuthN (Authentifizierung) bedeutet, den Benutzer zu identifizieren; AuthZ (Autorisierung) bedeutet, Berechtigungen anzuwenden. Viele KI-generierte Projekte implementieren den ersten Teil gut, weil Provider und Frameworks dies einfach machen: Social Login, Magic Links, Sitzungen, Refresh-Tokens, Basis-Middleware. Der zweite Teil erfordert jedoch Fachwissen: Rollen, Besitzverhältnisse, Mandanten (Tenants), Status, erlaubte Aktionen und Grenzen zwischen Kunden.

Die KI kann ein Dashboard generieren, das nur die Datensätze des aktuellen Benutzers anzeigt, aber das reicht nicht aus, wenn die eigentliche Abfrage eine user_id vom Client akzeptiert. Sie kann die Schaltfläche „Löschen“ vor Standardbenutzern verbergen, aber das reicht nicht aus, wenn der Endpunkt DELETE /api/users/123 die Rolle auf dem Server nicht überprüft. Sie kann eine separate Admin-Seite erstellen, aber das reicht nicht aus, wenn die Route mit einer beliebigen Sitzung erreichbar ist.

Die Grundregel lautet: Die Autorisierung muss im Backend liegen, in den Richtlinien und serverseitigen Kontrollen, nicht nur in der UI. Jede Anfrage, die Daten liest oder ändert, muss Identität, Rolle, Besitzverhältnis, Mandant und Objektstatus überprüfen.

BOLA und IDOR in KI-generierten Apps

Broken Object Level Authorization (BOLA) ist eines der am weitesten verbreiteten Probleme in modernen APIs: Ein authentifizierter Benutzer manipuliert einen Bezeichner und erhält Zugriff auf ein Objekt, das ihm nicht gehört. IDOR (Insecure Direct Object Reference) beschreibt dasselbe Problem aus der Sicht des offengelegten und manipulierbaren Bezeichners.

Typische Beispiele sind URLs und Bodies mit user_id, account_id, tenant_id, organization_id, project_id, document_id, order_id, invoice_id, ticket_id, message_id, workspace_id. Wenn die API diese ID verwendet, ohne zu prüfen, ob sie dem Benutzer oder dem Mandanten gehört, kann ein authentifizierter Angreifer Daten anderer lesen oder ändern.

KI-generierte Apps sind besonders anfällig für dieses Risiko, da der Code dazu neigt, den direktesten Weg zu gehen: eine ID aus der Route nehmen, eine Abfrage durchführen, das Ergebnis zurückgeben. Es funktioniert in der Demo und besteht den „Happy-Path“-Test, aber es fehlt die Kontrolle, die das Objekt mit der tatsächlichen Identität des Benutzers verknüpft.

Der einfachste Test: ID-Änderung

Erstelle vor der Veröffentlichung zwei Benutzer und mindestens zwei ähnliche Datensätze. Wenn die App B2B ist, erstelle zwei Mandanten oder Arbeitsbereiche. Melde dich mit dem ersten Benutzer an, fange eine Anfrage ab und ersetze die ID durch die des zweiten Benutzers, während du Lesen, Aktualisieren, Löschen, Exportieren und Herunterladen testest.

Dieser Test muss auf API-Ebene durchgeführt werden, nicht nur in der UI. Verwende Browser-Entwicklertools, Proxys, curl oder API-Clients und teste Detail-Endpunkte, Listen, Suchen, Anhänge, Berichte, CSV-Exporte, Admin-Funktionen, Einladungen, Zahlungen, Bestellungen, Benachrichtigungen und Webhooks. Die schwerwiegendsten Schwachstellen finden sich oft in Routen, die das Interface nicht direkt anzeigt.

Das erwartete Ergebnis ist immer das gleiche: 403, ein kontrollierter 404 oder eine verweigerte Antwort. Wenn die App Daten zurückgibt, einen Datensatz aktualisiert, eine Datei löscht oder einen Export erstellt, ist die Autorisierung fehlerhaft.

Mandantenisolierung: Das am meisten unterschätzte B2B-Problem

In SaaS-Apps und internen Multi-Mandanten-Tools ist die wichtigste Grenze nicht nur die zwischen Benutzern, sondern die zwischen Organisationen. Ein Benutzer gehört zu einem Mandanten, einem Arbeitsbereich, einem Unternehmen, einem Team, einem Projekt oder einem Kundenkonto, und jede Abfrage muss diese Grenze respektieren.

Das Risiko entsteht, wenn der Code nach user_id filtert, aber tenant_id vergisst, oder wenn er die tenant_id vom Frontend akzeptiert, anstatt sie aus der Sitzung oder einer verifizierten Mitgliedschaft abzuleiten. Ein Export-Endpunkt, ein Admin-Dashboard, eine Suchfunktion oder eine aggregierte Abfrage kann mandantenübergreifende Daten preisgeben, auch wenn die Hauptseiten korrekt erscheinen.

Um die Mandantenisolierung zu testen, erstelle zwei Organisationen mit ähnlichen Daten und Rollen und versuche dann, Dokumente, Bestellungen, Berichte, Benutzer, Dateien, Rechnungen und Protokolle des falschen Mandanten zu lesen. Teste auch Änderungsaktionen: Benutzer einladen, Rollen ändern, Daten löschen, Berichte exportieren, API-Schlüssel erstellen, Audit-Logs anzeigen. Ein einziger vergessener Endpunkt kann das gesamte B2B-Modell gefährden.

Clientseitige Kontrollen: Saubere UI, offene API

KI-App-Builder sind gut darin, überzeugende Interfaces zu erstellen: Sie zeigen unterschiedliche Komponenten je nach Rolle an, verbergen Schaltflächen, deaktivieren Felder, schützen Seiten mit Route Guards und generieren separate Menüs für Admins und Standardbenutzer. Diese Kontrollen verbessern die Benutzererfahrung, schützen die App aber nicht, wenn das Backend permissiv bleibt.

Ein Benutzer sollte nicht autorisiert sein, weil die Schaltfläche nicht erscheint, sondern weil der Server die Aktion ablehnt, wenn Berechtigung, Rolle, Besitzverhältnis oder Mandant nicht übereinstimmen. Jede clientseitige Kontrolle sollte als Komfortfunktion betrachtet werden, nicht als Sicherheitsbarriere.

Der praktische Test besteht darin, die APIs hinter der UI direkt aufzurufen: Wenn ein Standardbenutzer kein „Export“ sieht, sollte er den Export-Endpunkt trotzdem testen; wenn er kein „Löschen“ sieht, sollte er eine DELETE-Anfrage versuchen; wenn er das Admin-Panel nicht sieht, sollte er die Route versuchen; wenn ein Feld im Formular deaktiviert ist, sollte er den Body der Anfrage manipulieren.

Broken Function Level Authorization

BOLA betrifft Objekte; Broken Function Level Authorization betrifft Funktionen. Ein Benutzer kann möglicherweise keine Daten anderer lesen, aber dennoch Aktionen ausführen, die einer höheren Rolle vorbehalten sind: Benutzer einladen, Rollen ändern, Anfragen genehmigen, Rückerstattungen ausstellen, Inhalte veröffentlichen, Arbeitsbereiche löschen, Exporte generieren oder Konten imitieren.

In KI-generierten Apps passiert dies, wenn Rollen in der UI implementiert sind, aber nicht in den Routen: Der Code prüft, ob der Benutzer eingeloggt ist, aber nicht, ob er Admin, Owner, Billing Manager, Support oder ein autorisiertes Mitglied ist. Oder er verwendet ein vom Client gesendetes role-Feld, anstatt die Berechtigungen aus einem verifizierten Token oder der Datenbank zu lesen.

Definiere für jede sensible Funktion die Mindestmatrix: Wer darf sie ausführen, auf welchen Objekten, in welchem Status und mit welchen Limits? Teste dann die Aktion mit einer niedrigeren Rolle. Admin-Funktionen müssen standardmäßig fehlschlagen und nicht verfügbar bleiben, bis jemand das Problem bemerkt.

Rollen, Berechtigungen und Claims: Wo man vertrauen kann und wo nicht

Rollen und Berechtigungen können von Auth0, Supabase, Firebase Custom Claims, der internen Datenbank oder Unternehmenssystemen stammen. Der kritische Teil ist, wo sie überprüft werden: Das Backend muss Token, Signatur, Ablaufdatum, Issuer und Audience validieren, wenn es JWT oder Access Tokens verwendet, und dann Rolle und Berechtigungen in Anwendungsentscheidungen übersetzen.

Vertraue nicht auf role, isAdmin, user_id, tenant_id oder permissions, die im Body vom Frontend gesendet werden. Vertraue weder dem Local Storage noch einem versteckten Feld im Formular: Ein Benutzer kann Anfragen und Header ändern. Wenn eine Sicherheitsentscheidung von einem vom Client steuerbaren Wert abhängt, ist diese Entscheidung fragil.

Überprüfe in einer KI-generierten App, wo die Rolle berechnet wird. Wenn der Code if (user.role === "admin") im Frontend anzeigt, suche auch nach der entsprechenden Kontrolle auf der Serverseite. Wenn diese nicht existiert, schützt die Rolle nur das Interface, nicht die Aktion.

Middleware und neue, von der KI generierte Routen

Ein häufiges Problem ist die unvollständige Abdeckung durch Middleware. Das Projekt hat eine Auth-Middleware für einige Routen, aber die KI fügt eine neue API, eine Server Action, eine Edge-Funktion, eine Cloud Function oder einen Export-Endpunkt hinzu, ohne ihn an dieselbe Kontrolle anzubinden – die Route funktioniert, wird aber vergessen.

Dieses Risiko steigt, wenn der Agent Refactoring über mehrere Dateien hinweg durchführt oder ganze Features erstellt: neue Seiten, neue Handler, neue Modelle, neue Endpunkte und neue Tests. Wenn das Autorisierungsmuster nicht zentralisiert ist, wird jede neue Route zu einer manuellen Entscheidung.

Erstelle vor dem Go-Live ein Inventar der Routen und frage dich für jede: Erfordert sie Login? Erfordert sie eine Rolle? Erfordert sie Besitzverhältnisse? Erfordert sie einen Mandanten? Akzeptiert sie IDs vom Client? Gibt sie Daten zurück? Ändert sie den Status? Erstellt sie Exporte? Wenn du das nicht beantworten kannst, muss diese Route getestet werden.

Workflow außerhalb der Sequenz

Autorisierungsschwachstellen betreffen nicht nur Objekte und Rollen, sondern auch den Workflow-Status. Eine Einladung kann wiederverwendet werden, ein Passwort-Reset-Link kann gültig bleiben, eine Bestellung kann nach der Zahlung geändert werden, eine Anfrage kann zweimal genehmigt werden, eine Rückerstattung kann ohne korrekten Status aufgerufen werden, ein Dokument kann vor der Überprüfung veröffentlicht werden.

Der von der KI generierte Code kann die einzelnen Schritte implementieren, ohne die Sequenz zu schützen: Die UI führt den Benutzer durch den richtigen Ablauf, aber die API akzeptiert Aufrufe außerhalb der Reihenfolge. Es handelt sich um einen Missbrauch der Geschäftslogik, bei dem der Angreifer nicht das Login bricht, sondern legitime Funktionen zum falschen Zeitpunkt nutzt.

Überprüfe bei kritischen Abläufen Status und Berechtigungen gemeinsam: Es reicht nicht zu wissen, dass der Benutzer der Owner ist; man muss wissen, ob sich das Objekt in dem Status befindet, der diese Aktion zulässt. Einladungen, Zahlungen, Genehmigungen, Exporte, Veröffentlichungen, Löschungen und Rollenänderungen verdienen alle negative Tests.

Routen, die oft der Überprüfung entgehen

Autorisierungsschwachstellen finden sich oft in sekundären Routen, nicht auf dem Hauptbildschirm. Eine Detailseite kann geschützt sein, aber der Export-Endpunkt kann mehr Daten zurückgeben als vorgesehen; ein Dashboard kann nach Mandanten filtern, aber eine globale Suchfunktion kann die gesamte Datenbank abfragen; ein Upload kann an den Benutzer gebunden sein, aber der Download kann nur vom Dateipfad abhängen.

Überprüfe sorgfältig Endpunkte für Autocomplete, Suche, CSV-Exporte, Berichte, aggregierte Dashboards, Webhooks, Callbacks, Benachrichtigungen, Uploads, Downloads, Vorschauen, Batch-Funktionen, Cron-Jobs, Imitation, Einladungen, Passwort-Resets, Abrechnung, Rückerstattungen und Rollenänderungen. Dies sind Funktionen, die oft hinzugefügt werden, um das MVP zu vervollständigen, und die weniger auf Missbrauch getestet werden.

KI-generierte Apps können diese Routen als Unterstützung für das Hauptfeature erstellen: Der Prompt lautet „Export hinzufügen“, „Admin-Dashboard hinzufügen“, „Benutzereinladung hinzufügen“, „Dokumenten-Upload hinzufügen“. Der resultierende Code kann funktional korrekt sein, erbt aber nicht immer dieselben Richtlinien wie die bereits bestehenden Routen.

Praktische Beispiele für Missbrauch zum Testen

In einer SaaS-Lösung mit Arbeitsbereichen sollte ein Standardbenutzer versuchen, /api/workspaces/{id}/members eines anderen Arbeitsbereichs zu lesen, Bestellungen eines anderen Mandanten zu exportieren, die Rolle eines Kollegen zu ändern, einen fremden API-Schlüssel zu regenerieren oder Dateien herunterzuladen, die von einem anderen Kunden hochgeladen wurden. Wenn einer dieser Fälle funktioniert, liegt das Problem nicht am Login: Es liegt am Autorisierungsmodell.

Versuche in einer E-Commerce-App oder einem Marktplatz, order_id, seller_id, customer_id, payment_id und refund_id zu ändern. Ein Benutzer darf keine Bestellungen anderer sehen, Preise ändern, auf Quittungen anderer Kunden zugreifen oder Rückerstattungsfunktionen außerhalb seiner Rolle aufrufen. Auch Webhooks müssen überprüft werden: Ein Callback darf den Status einer Bestellung nicht aktualisieren, ohne Signatur, Status und Besitzverhältnisse zu validieren.

Probiere in einem schnell generierten internen Tool Funktionen aus, die harmlos erscheinen: Exporte, erweiterte Filter, Suche, Datensatz-Duplizierung, Zuweisungsänderungen, Zugriff auf Kommentare, Download von Anhängen und Anzeige von Audit-Logs. Interne Tools verarbeiten oft sensible Unternehmensdaten und haben weniger Härtung, da sie nicht als öffentliche Produkte wahrgenommen werden.

RLS und Security Rules helfen, reichen aber allein nicht aus

Supabase Row Level Security (RLS), Firebase Security Rules und ähnliche Kontrollen sind wichtige Abwehrmechanismen und können direkte Zugriffe auf die Datenbank oder den Speicher blockieren, wenn die App clientseitige SDKs verwendet. Sie ersetzen jedoch nicht die Anwendungsautorisierungslogik für APIs, serverseitige Funktionen, Exporte, Aggregationen, Rollen und Workflows.

Wenn eine serverseitige API einen Service-Key oder eine privilegierte Rolle verwendet, muss sie eine Autorisierung anwenden, bevor sie Abfragen ausführt oder Daten zurückgibt. Wenn eine Funktion einen aggregierten Bericht erstellt, muss sie Mandanten und Berechtigungen respektieren. Wenn ein Endpunkt Daten exportiert, muss er Kontrollen haben, die mindestens so stark sind wie die der Bildschirme, die er anzeigt.

Das solideste Modell kombiniert mehrere Ebenen: Richtlinien auf der Datenbank, wo nötig, zentralisierte serverseitige Kontrollen, manuelle Tests von APIs und Rollen, Protokollierung sensibler Aktionen und Code-Reviews der Zugriffskontrollbereiche.

Wie man korrigiert, ohne fragile Patches zu vervielfachen

Wenn du eine BOLA oder eine Funktion findest, die für die falsche Rolle zugänglich ist, vermeide es, nur den spezifischen Endpunkt mit einer lokalen Bedingung zu korrigieren. Wenn das Problem aus einem wiederkehrenden Muster stammt, muss die Kontrolle zentralisiert werden: Middleware, Autorisierungs-Helper, geteilte Richtlinien, sichere Query-Builder oder Service-Layer können das Risiko verringern, dass die nächste von der KI generierte Route denselben Fehler wiederholt.

Die Behebung sollte beim Modell beginnen: Welche Rollen existieren, welche Objekte schützen sie, welche Mandanten trennen sie, welche Aktionen sind erlaubt und welche Workflow-Status sind gültig? Dann muss der Code dieses Modell einheitlich anwenden, denn wenn jede Route autonom entscheidet, was „Admin“ oder „Owner“ bedeutet, hängt die Sicherheit vom Gedächtnis des einzelnen Entwicklers oder dem verwendeten Prompt ab.

Füge für jeden korrigierten Bug einen negativen Test hinzu. Wenn ein Benutzer ein Dokument eines anderen Mandanten lesen konnte, muss der Test beweisen, dass er jetzt eine verweigerte Antwort erhält. Wenn eine niedrige Rolle einen Admin-Endpunkt aufrufen konnte, muss der Test in der Pipeline bleiben. Die Korrektur wird erst dann zuverlässig, wenn das falsche Verhalten nicht mehr auftreten kann, ohne eine Prüfung fehlschlagen zu lassen.

Negative Tests, die nicht fehlen dürfen

KI-generierte Tests decken oft den „Happy Path“ ab: Login erfolgreich, Benutzer korrekt, Daten vorhanden, Rolle vorgesehen. Für Autorisierungen sind gegenteilige Tests erforderlich, bei denen jede kritische Funktion beweist, dass der falsche Benutzer die Aktion nicht ausführen kann.

Bereite Fälle vor für: nicht authentifizierter Benutzer, abgelaufenes Token, unzureichende Rolle, anderer Mandant, Objekt eines anderen Benutzers, nicht existierende ID, andere HTTP-Methode, manipulierter Body, ungültiger Status, bereits verwendete Einladung, abgelaufener Link, nicht autorisierter Export, Upload außerhalb des Pfads und nicht erlaubtes Löschen.

Diese Tests sollten nicht nur manuell bleiben: Nachdem du ein Problem gefunden hast, wandle es in einen Regressionstest um. KI-generierte Apps ändern sich schnell. Wenn ein Agent also Middleware oder Abfragen ändert, muss ein negativer Test dies bemerken.

Wann eine unabhängige Überprüfung erforderlich ist

Eine interne Überprüfung kann für Prototypen ohne echte Daten, ohne externe Benutzer und mit wenigen Routen ausreichen. Eine unabhängige Überprüfung ist jedoch erforderlich, wenn die App online exponiert ist, echte Daten verarbeitet, verschiedene Rollen hat, Mandanten oder Arbeitsbereiche verwendet, APIs exponiert, Exporte erstellt, Zahlungen verwaltet, Admin-Funktionen nutzt oder aus umfangreichen KI-generierten Änderungen stammt.

Ein WAPT (Web Application Penetration Test) ist besonders nützlich, da er das reale Verhalten von außen und als authentifizierter Benutzer testet: Er liest nicht nur den Code, sondern versucht manipulierte IDs, versteckte Routen, unzureichende Rollen, gekreuzte Mandanten und Abläufe außerhalb der Sequenz. Die Code-Review ist nützlich, wenn man verstehen muss, warum die Kontrolle fehlt: nicht angewandte Middleware, falsche Abfrage, Rolle vom Client gelesen, unvollständige Richtlinie, duplizierte Logik. Die beiden Ansätze sind oft komplementär: Einer beweist den Missbrauch, der andere identifiziert die Ursache.

Wie ISGroup Auth, Rollen und APIs überprüfen kann

ISGroup kann die Autorisierungen einer KI-generierten App basierend auf dem realen Verhalten testen: Benutzer, Rollen, APIs, Mandanten, Objekte, Admin-Funktionen, Exporte, Uploads und kritische Workflows. Das Ziel ist es, vor dem Go-Live zu beweisen, ob ein authentifizierter Benutzer seinen Bereich verlassen kann.

Wenn die KI-generierte App hat…	Hauptrisiko	Empfohlene Prüfung
Web-Apps, APIs, Login, Rollen, Mandanten oder Uploads online	BOLA, IDOR, Auth-Bypass, Rollenmissbrauch	Web Application Penetration Testing
Middleware, Abfragen, Controller, Server Actions oder Richtlinien im Code	Unvollständige serverseitige Kontrollen	Code Review
Supabase, Firebase, Auth0, RLS, Security Rules oder Callbacks	Richtlinien und Konfigurationen nicht konsistent mit der Anwendungslogik	Cloud Security Assessment
Mehrere KI-generierte Releases zu Auth und API	Wiederholte Regressionen bei der Zugriffskontrolle	Software Assurance Lifecycle

Hast du eine KI-generierte Web-App mit Login, Rollen, Mandanten oder exponierten APIs? ISGroup kann vor dem Go-Live überprüfen, ob authentifizierte Benutzer auf Daten oder Funktionen außerhalb ihres Bereichs zugreifen können.

Vorbereitende Nachweise

Bereite Umgebungs-URLs, Repositories, eine Liste der Routen und APIs, Rollen, Mandanten oder Arbeitsbereiche, Auth-Provider, Datenschemata, Datenbankrichtlinien, Middleware, Admin-Funktionen, Exporte, Uploads, Zahlungen und von der KI generierte oder geänderte Teile vor.

Es werden realistische Test-Accounts benötigt: mindestens zwei Standardbenutzer, ein Admin, zwei Mandanten oder Arbeitsbereiche (falls vorhanden), ähnliche Daten zwischen Benutzern und Objekte mit bekannten IDs. Gib für jede Rolle an, welche Aktionen sie ausführen können sollte und welche verweigert werden müssen.

Wenn es unsichere Bereiche gibt, bringe sie sofort in die Überprüfung ein: von der KI hinzugefügte Routen, duplizierte Kontrollen, nicht zentralisierte Middleware, nicht verifizierte RLS, clientseitig verwendete Claims, für Demos erstellte Exporte, nicht dokumentierte Admin-Funktionen.

Entscheidung vor dem Go-Live

Stoppe das Go-Live, wenn:

• Ein authentifizierter Benutzer Daten anderer Benutzer oder Mandanten lesen, ändern, löschen oder exportieren kann.
• Eine niedrige Rolle auf Admin-Funktionen zugreifen kann.
• Die API auf IDs oder Rollen vertraut, die vom Client gesendet werden.
• Eine sensible Route Sitzung und Berechtigungen nicht überprüft.
• Ein kritischer Workflow außerhalb der Sequenz ausgeführt werden kann.

Du kannst Verbesserungen, die keine Daten oder Funktionen exponieren, auf die Zeit nach der Veröffentlichung verschieben: Refactoring des RBAC-Modells, Dokumentation der Rollen, Erhöhung der Testabdeckung, schrittweise Zentralisierung der Middleware. Erkenntnisse zu BOLA, IDOR, Mandantenisolierung und nicht autorisierten Admin-Funktionen müssen vor der Verarbeitung echter Daten und externer Benutzer korrigiert werden.

Checkliste Auth und Autorisierungen

• Liste alle Routen auf, die Daten lesen, ändern, löschen oder exportieren.
• Verknüpfe jede Route mit der erforderlichen Rolle, Besitzverhältnis, Mandant und Status.
• Teste manipulierte IDs: user_id, tenant_id, project_id, order_id, document_id, invoice_id.
• Teste verschiedene Benutzer, verschiedene Mandanten, fehlende Token, abgelaufene Token und niedrige Rollen.
• Rufe die APIs direkt auf, ohne die UI zu nutzen.
• Überprüfe Admin-Funktionen: Einladen, Exportieren, Löschen, Rollen ändern, Imitieren, Rückerstatten, Genehmigen.
• Stelle sicher, dass das Backend keine Rolle oder Benutzer-ID vom Client liest.
• Überprüfe die Middleware bei neuen Routen, Server Actions, Funktionen und Webhooks.
• Füge für jeden gefundenen Bug einen negativen Test hinzu.
• Veröffentliche nicht, wenn ein Benutzer seinen Bereich verlassen kann.

Häufig gestellte Fragen

• Wenn ich Auth0, Supabase Auth oder Firebase Authentication verwende, bin ich dann geschützt?
• Nein. Diese Tools authentifizieren den Benutzer, aber deine App muss dennoch den Zugriff auf Daten, Objekte, Rollen und Funktionen autorisieren.
• Wie erkenne ich, ob ich eine BOLA habe?
• Melde dich als Benutzer A an, fange eine Anfrage mit der ID eines Objekts ab und ersetze sie durch eine ID von Benutzer B. Wenn du Daten erhältst oder das Objekt ändern kannst, hast du ein Problem.
• Reicht es aus, eine Schaltfläche in der UI zu verbergen?
• Nein. Die API hinter dieser Schaltfläche muss die Anfrage auch dann ablehnen, wenn sie direkt aufgerufen wird, unabhängig davon, was das Interface anzeigt.
• Reichen RLS oder Firebase Security Rules aus?
• Sie sind wichtige Kontrollen, aber du musst auch serverseitige APIs, Exporte, Admin-Funktionen, Speicher, Workflows und Middleware überprüfen.
• Wann ist ein WAPT erforderlich?
• Wenn Apps und APIs online exponiert sind oder es bald sein werden. Der WAPT testet Rollen, Objekte, Mandanten und Routen, wie es ein authentifizierter Angreifer tun würde.
• Wann ist eine Code-Review erforderlich?
• Wenn du verstehen musst, ob serverseitige Kontrollen, Middleware, Abfragen, Rollen und Richtlinien im von der KI generierten oder geänderten Code korrekt implementiert sind.

[Callforaction-WAPT-Footer]

Quellen und nützliche Referenzen

• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• OWASP Broken Access Control: https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html