Eine vibe-codierte API absichern: Die Lücken in der Zugriffskontrolle, die KI-Assistenten regelmäßig übersehen

Sicherheitsprobleme beim Vibe Coding sehen selten aus wie Bugs. Der Code kompiliert, die Tests laufen durch, und der Endpunkt liefert die richtigen Daten zurück. Doch sobald du die Autorisierungslogik untersuchst, findest du immer wieder dieselben Lücken: Endpunkte, die prüfen, ob du eingeloggt bist, aber nicht, ob du das darfst, was du gerade anforderst. Rollenprüfungen, die sich leicht umgehen lassen, weil sie in der falschen Schicht liegen. Und Admin-Routen, die lediglich versteckt statt geschützt sind. Dieser Beitrag geht die Schwachstellen in der Zugriffskontrolle durch, die uns beim Audit vibe-codierter APIs am häufigsten begegnen, und zeigt, was es wirklich braucht, um sie zu beheben.

Warum KI-Assistenten Autorisierung falsch machen

Sprachmodelle werden auf riesigen Mengen Code trainiert, der größtenteils entweder Tutorial-Code ist oder Produktivcode aus einer Zeit, bevor moderne Autorisierungsmuster Standard wurden. Wenn du eine KI bittest, einen REST-Endpunkt zu generieren, schöpft sie aus genau dieser Verteilung. Das Ergebnis ist Code, der vernünftig aussieht und den Happy Path korrekt abdeckt. Aber bei Autorisierung geht es nicht um den Happy Path.

Autorisierung ist ihrem Wesen nach defensiv. Ihre Aufgabe ist es, vorwegzunehmen, was ein böswilliger oder irrender Nutzer versuchen könnte, und es zu blockieren. KI-Assistenten sind darauf optimiert, Code zu erzeugen, der die formulierte Anforderung erfüllt, nicht darauf, sich Angriffsszenarien vorzustellen. Wenn du einen Endpunkt anforderst, der "Nutzern erlaubt, ihr Profil zu aktualisieren", schreibt die KI Code, der Nutzern erlaubt, ein Profil zu aktualisieren. Ob dabei sichergestellt ist, dass Nutzer nur ihr eigenes Profil ändern können, ist eine andere Frage, die es selten in den Prompt schafft.

Das Ergebnis ist eine wiederkehrende Klasse von Schwachstellen: Autorisierung, die dem Geist nach vorhanden, in der Praxis aber gebrochen ist.

Broken Object Level Authorization (BOLA): die häufigste Lücke

BOLA, manchmal auch Insecure Direct Object Reference genannt, ist der mit Abstand häufigste Befund in vibe-codierten APIs. Das Muster sieht so aus:

GET /api/invoices/4821

Der Endpunkt prüft, ob die Anfrage ein gültiges JWT mitbringt. Er lädt die Rechnung mit der ID 4821. Er gibt sie zurück. Was er nicht prüft: ob der authentifizierte Nutzer die Rechnung 4821 überhaupt besitzt.

Ein Angreifer, der ein legitimer Nutzer ist, iteriert einfach über die Rechnungs-IDs. Weil IDs oft fortlaufende Ganzzahlen sind, kann ein Skript innerhalb von Minuten jede Rechnung im System durchzählen. Keine besonderen Rechte nötig. Kein raffinierter Angriff. Nur ein gültiges Session-Token und eine Schleife.

KI-Assistenten erzeugen dieses Muster ständig. Die Authentifizierungsprüfung ist da, denn das Modell hat gelernt, dass Endpunkte Authentifizierung brauchen. Aber die Besitzprüfung erfordert eine fachliche Entscheidung, die nicht im Prompt stand.

Der Fix braucht eine zusätzliche Bedingung in der Abfrage:

WHERE invoice.id = :id AND invoice.user_id = :authenticated_user_id

Einfach zu schreiben, leicht zu übersehen und in KI-generiertem Code fast nie enthalten, solange du nicht ausdrücklich danach fragst.

Function Level Authorization: Admin-Routen, die nur versteckt sind

Eine andere Problemkategorie sind Endpunkte, die existieren, aber nicht beworben werden. Vibe-codierte Anwendungen haben oft Admin-Funktionalität wie Massenexporte, Nutzerverwaltung oder Konfigurationsänderungen, die die KI ohne Rollenprüfung implementiert hat, weil die Entwicklerin sie nur gebeten hat, das Feature zum Laufen zu bringen. Die Annahme "das nutzen ohnehin nur Admins" ist im Code nicht durchgesetzt.

Das zeigt sich auf vorhersehbare Weise. Admin-Routen folgen häufig konventionellen Namen: /api/admin/users, /api/v1/management/export, /api/internal/config. Ein fähiger Angreifer probiert diese Pfade durch. Wenn der Endpunkt für ein Nicht-Admin-Token 200 statt 403 zurückgibt, ist das Feature offen.

Der richtige Fix ist eine explizite Rollenprüfung auf Routen-Ebene, nicht auf UI-Ebene. Einen Button im Frontend zu verstecken bringt gar nichts. Jeder Endpunkt, der eine privilegierte Aktion ausführt, muss vor der Verarbeitung prüfen, ob der Aufrufer die passende Rolle hat, unabhängig davon, wie er an die URL gekommen ist.

Wenn du mit einem vibe-codierten Backend arbeitest und nicht sicher bist, ob jeder Admin-Endpunkt einen expliziten Rollen-Guard hat, behandle ihn als ungeschützt, bis du es geprüft hast.

Fehlende Mandantentrennung in Multi-Tenant-APIs

SaaS-Anwendungen, die mit KI-Unterstützung entstanden sind, haben oft ein subtileres Problem: Das Autorisierungsmodell ist innerhalb eines Mandanten korrekt, fällt aber zwischen Mandanten auseinander. Der Code prüft, dass der Nutzer authentifiziert ist und vielleicht die richtige Rolle hat. Er prüft nicht, dass die Ressource, auf die zugegriffen wird, zur Organisation des Nutzers gehört.

Besonders häufig ist das in Anwendungen, bei denen die KI das Datenmodell und die API-Schicht getrennt generiert hat. Das Datenmodell hat eine tenant_id-Spalte. Die API prüft die Rolle des Nutzers. Niemand hat beides verbunden, denn dafür müsste man das vollständige Datenmodell und die Autorisierungsanforderungen gleichzeitig im Kopf haben. Aus einem iterativen, Prompt-für-Prompt-Entwicklungsprozess entsteht das selten.

Der Fix erfordert Systematik: Jede Abfrage, die eine mandantengebundene Ressource liest oder verändert, muss die Mandanten-ID als Filterbedingung enthalten, und zwar abgeleitet aus der authentifizierten Session, nicht aus den Request-Parametern. Request-Parameter lassen sich fälschen. Session-Daten nicht, sofern die Session sauber implementiert ist.

Fehlendes Rate Limiting lädt zu Brute Force ein

Weniger offensichtlich, aber verwandt ist das Fehlen von Rate Limiting an sensiblen Endpunkten. Passwort-Reset-Flows, Authentifizierungsendpunkte, OTP-Verifizierung: Sie alle brauchen Rate Limiting, um Brute Force zu verhindern. KI-Assistenten erzeugen den Happy Path dieser Abläufe korrekt, fügen aber ungefragt selten Rate Limiting hinzu.

Der Grund ist derselbe wie bei der Autorisierung: Rate Limiting ist defensiv und vorausschauend. Es verlangt, sich vorzustellen, was passiert, wenn etwas schiefgeht, und nicht nur, was passiert, wenn es funktioniert. Diese Art von adversarialem Denken ist nicht der Standardmodus eines Codegenerators.

Wie eine systematische Prüfung der Zugriffskontrolle aussieht

Diese Lücken zu finden und zu schließen ist in erster Linie keine Aufgabe des Codeschreibens. Es erfordert, den bestehenden Code mit einer bestimmten angreiferischen Haltung zu lesen:

Frage bei jedem Endpunkt: Was passiert, wenn in jedem Parameter und jedem Pfadsegment die ID des authentifizierten Nutzers durch die ID eines anderen Nutzers ersetzt wird? Liefert oder verändert der Endpunkt dann immer noch ausschließlich Daten, die dem authentifizierten Nutzer gehören?

Frage bei jeder privilegierten Aktion: Liegt die Rollenprüfung im Route-Handler oder nur in der UI? Könnte ein Aufrufer die UI umgehen und den Endpunkt direkt ansprechen?

Frage bei jeder Abfrage auf Mandantendaten: Stammt die Mandanten-ID aus der Session oder aus dem Request? Und wenn sie aus dem Request kommt, lässt sie sich fälschen?

Dieser Prozess ist nicht kompliziert, aber er ist methodisch. Er dauert länger, als das Generieren des Codes gedauert hat, und er verlangt, das System als Ganzes zu lesen statt Prompt für Prompt. Genau deshalb passiert er während vibe-codierter Entwicklung praktisch nie, und genau deshalb muss er passieren, bevor die Anwendung echte Nutzer und echte Daten verarbeitet.

Wenn du einen strukturierten Ansatz für eine solche Prüfung suchst: Unsere Arbeit im Bereich Code Quality Consulting deckt Audits der Zugriffskontrolle als Teil einer breiteren Sicherheits- und Architekturprüfung ab. Der Prozess, den wir nutzen, kartiert jeden Ressourcentyp der API, verfolgt die Autorisierungslogik jedes Endpunkts und liefert eine priorisierte Liste der Lücken samt empfohlener Fixes.

Was tun, wenn die vibe-codierte API schon live ist

Wenn du eine vibe-codierte API im Produktivbetrieb hast, ist die dringende Frage nicht, ob diese Lücken existieren. Sie tun es mit hoher Wahrscheinlichkeit. Die Frage ist, welche davon am stärksten exponiert und am folgenreichsten sind.

Fang mit BOLA an. Suche jeden Endpunkt, der eine Ressource über eine ID lädt oder verändert, und prüfe, ob die Abfrage eine Besitzbedingung enthält. Das ist die häufigste, die am leichtesten ausnutzbare und die am unkompliziertesten zu behebende Lücke.

Prüfe danach die privilegierten Routen. Liste jeden Endpunkt auf, der eine administrative oder destruktive Aktion ausführt, und stelle sicher, dass er eine explizite Rollenprüfung im Handler hat, nicht nur in der UI.

Sieh dir anschließend deine Multi-Tenancy-Logik an, sofern relevant. Verfolge, wie die Mandanten-ID durch das System fließt, und prüfe, dass sie an jeder relevanten Stelle aus der Session stammt.

Nichts davon erfordert einen Neubau der API. Das sind gezielte Korrekturen, und die meisten sind klein. Die Herausforderung besteht darin, sie alle zu finden, und das gelingt nur, wenn man den Code systematisch liest, statt der KI-generierten Dokumentation zu vertrauen.

Externe Augen auf das Problem

Das Schwierige beim Audit der eigenen vibe-codierten Codebasis ist, dass du sie auf Vorwärtsbewegung hin optimiert gebaut hast. Die Lücken fühlen sich unsichtbar an, weil du beim Generieren des Codes nicht angreiferisch gedacht hast. Eine externe Prüfung durch jemanden, der gezielt nach Autorisierungsfehlern sucht, findet Dinge, die man leicht übersieht, wenn man weiß, was der Code eigentlich tun soll.

Wenn du eine vibe-codierte API hast und dir bei der Zugriffskontrolle nicht sicher bist, helfen wir gern. Unsere Praxis für Custom Software Development umfasst Teams, die regelmäßig KI-generierte Backends auditieren und wissen, wo sie hinschauen müssen. Schreib uns an hello@wolf-tech.io oder schau auf wolf-tech.io vorbei, um zu besprechen, was eine Prüfung konkret umfassen würde.

Die hier beschriebenen Muster sind nicht theoretisch. Sie tauchen in echten Anwendungen auf, die echte Nutzer bedienen. Sie zu finden, bevor es jemand anderes tut, ist eine Frage des Wann, nicht des Ob.