AI-first Security Review: Vibe-Coded App im Praxistest

In einem meiner letzten Aufträge ging es darum, ein Security Review für eine komplett ge-vibecodete App zu erstellen und potenzielle Lücken zu finden, die durch den Vibecoding Prozess im Code entstanden sind. Als Challenge an mich habe ich dafür das erste Mal einen AI-first Ansatz genutzt, d.h. ich habe mit AI eine durch AI programmierte App reviewed. Dabei hatte ich einige interessante Learnings und natürlich auch Fails und vielleicht kann ich ja ein paar von euch damit helfen.

Verwandt: Die Schwachstelle, die nur die KI gefunden hat  ·  API-Sicherheit im Unternehmen: In 5 Schritten zur robusten Schnittstellenstrategie

„Finde Sicherheitslücken“ hat nicht funktioniert

Mehr stand in meiner ersten Prompt nicht.

Ich wollte einen Security Review und habe Codex nicht einmal gesagt, was der Scope davon sein soll. Der Prompt enthielt außerdem kein Angreifermodell und keine Anforderungen an Belege. Er unterschied auch nicht zwischen einer auffälligen Codestelle und einer Schwachstelle, die ein Angreifer tatsächlich erreichen kann.

Das Ergebnis war entsprechend schlecht. Es ließ sich nicht in einen belastbaren Bericht überführen, weil mir die Kette zwischen Vermutung, Codepfad, Auswirkung und Gegenprobe fehlte. Wenn ihr gerade selbst einen KI-gestützten Review vorbereitet, könnt ihr euch diesen Einstieg sparen. Ein offener Prompt ersetzt keinen Prüfauftrag.

Zuerst musste ich verstehen, was ich überhaupt prüfen wollte

Bei der App hat es sich um eine webbasierte Plattform gehandelt, die mit intensiver KI-Unterstützung entwickelt wurde. Keiner der Devs hatte einen Security Hintergrund, entsprechend wurde bei der Entwicklung auch nicht darauf geachtet.

Der Stack bestand aus einem Next.js-Frontend, Route Handlern als Backend for Frontend (BFF) und einem Xano-Backend. Dort lagen Datenbankabfragen, Benutzer- und Projektlogik sowie Dateioperationen.

Mein zweiter Anlauf begann deshalb mit einer Bestandsaufnahme statt mit einer neuen Variante von „Suche gründlicher“. Ich habe mir einen Überblick über die Komponenten, Benutzereingaben, Sessions, Rollen und schreibenden Aktionen geschaffen. Vor allem wollte ich wissen, welche Schicht am Ende wirklich entscheidet, ob eine Aktion erlaubt ist. Genau diese Frage solltet ihr für euren eigenen Review möglichst früh beantworten.

Die verbesserte Fassung des Prompts sah ungefähr so aus:

Dieser Prompt war besser, weil er eine Arbeitsweise vorgab. Die wichtigste Verbesserung kam aber beim Zeichnen der Architektur.

Das Architekturproblem

Im Browser setzte die Anwendung einen Session-Cookie. Das BFF las dieses Cookie, wandelte es in einen Bearer-Token um und rief damit Xano auf. Soweit so gut, allerdings hat sich damit ein neues Problem ergeben:

Die untere Verbindung veränderte den gesamten Review. Wenn man nur den normalen Weg durch die Anwendung betrachtet, übersieht man diese Möglichkeit unter Umständen.

Alle Xano Endpoints hingen direkt im Internet und waren öffentlich erreichbar. Die URLs der Endpoints konnte man aus den Netzwerkverbindungen in den Browsertools auslesen und so als Angreifer den Umweg über das BFF überspringen und direkt das Xano Backend angreifen.

Jede Autorisierungsprüfung, die ausschließlich im React-Frontend oder im BFF stattfand, ließ sich damit umgehen.

Ich hatte das BFF und Xano Backend anfangs wie zwei gleichwertige Prüfflächen behandelt. Für die Frage „Wer darf welche Daten lesen oder verändern?“ war das falsch. Xano war die einzige verbindliche Grenze. Das Frontend blieb wichtig für Cross-Site-Scripting und Session-Schutz, das BFF blieb wichtig für Errorhandling, Caching und zusätzliche Rollenprüfungen. Aber beide konnten einen direkten Backend-Aufruf nicht verhindern.

Ab diesem Punkt wurde mein Prompting konkreter:

Codex Security für mehr Struktur

Ab diesem Punkt habe ich das Codex Security Plugin genutzt. Die einzelnen Aufgaben wurden durch die bereits vorhandenen Skills aus dem Plugin genauer bearbeitet und in meinem Fall auf sechs Sub-Agents verteilt.

Jeder davon bearbeitete einen abgegrenzten Suchauftrag und konnte Codepfade durch die Xano Endpoints, Funktionen und Datenbankzugriffe verfolgen. Statt dass ein einzelner Chat nacheinander durch alle Dateien sprang, liefen mehrere Analysen parallel. Das half vor allem bei einer größeren Codebasis: Mehr Pfade wurden abgedeckt und auffällige Stellen aus unterschiedlichen Blickwinkeln betrachtet. Die Kandidaten wurden anschließend zusammengeführt und Dopplungen bereinigt.

Zuerst entstand ein Threat Model mit Angreifern, Daten und verbindlichen Sicherheitsregeln. Danach durfte Codex in der Discovery breit nach verdächtigen Codepfaden suchen. Interessant waren vor allem Endpoints, die zwar einen eingeloggten User voraussetzten, aber keine Adminrolle, aktive Projektmitgliedschaft oder Ownership prüften.

In der anschließenden Validation ging es um Belege statt um mehr Kandidaten: Gibt es doch noch eine Prüfung in einem nachgelagerten Codepfad? Ist der Endpoint im verwendeten Xano Branch aktiv? Kann der angenommene Angreifer ihn wirklich erreichen? Diese Trennung hat verhindert, dass eine plausible Vermutung einfach immer weiter ausformuliert wurde.

Der erste statische Scan ergab 20 reportable Findings. Das waren aber noch keine bestätigten Sicherheitslücken, da zu diesem Zeitpunkt die echte API noch nicht mit echten Requests getestet wurde.

Das Verifikationsframework

Ein Finding kann im erstellten Report eindeutig aussehen und in der bereitgestellten Anwendung trotzdem nicht funktionieren. Der aktive Xano Branch kann abweichen, eine Plattformfunktion kann im Export fehlen oder die angenommene Rolle verhält sich anders.

Deshalb habe ich ein Verifikationsframework gebaut. Mit Bruno habe ich zuerst händisch verschiedene APIs getestet um ein Gefühl für deren Verhalten zu bekommen. Anschließend habe ich mit einem Python Runner die Requests systematisch und automatisiert gegen die DEV API prüfen lassen.

Bruno war dabei meine Bibliothek für reproduzierbare Testfälle. Zu einem Finding gehörten je nach Bedarf ein Login oder Setup, der Proof-Request und eine Kontrollprobe. Darin hielt ich Hypothese, benötigte Rolle, Voraussetzungen sowie das erwartete Verhalten fest. Der Runner setzte die Variablen aus der Dev-Umgebung ein und wählte die passenden Probes aus.

Wichtig waren mir die Sicherheitsbremsen. Ohne --execute erzeugte der Runner nur einen Dry-Run. Schreibende Requests benötigten mit --allow-mutating eine zweite Freigabe. Außerdem war der Runner auf die direkten Xano Endpoints und die Dev-Umgebung begrenzt.

Status, Response und Laufzeit wurden dokumentiert. Tokens, Passwörter und Cookies entfernte der Runner vorher. Die redigierte Evidence landete als JSON und lesbarer Markdown-Report im Evidence-Paket.

Ein 401 oder 403 Statuscode sprach für eine funktionierende Zugriffskontrolle, ein 400 konnte dagegen auch durch ungeeignete Testdaten entstehen. Selbst ein 200 bewies bei einer schreibenden Aktion noch nicht, dass der unerlaubte Zustand wirklich gespeichert wurde. Dafür brauchte es eine anschließende Zustandsprüfung und einen berechtigten User als Positivkontrolle.

Voraussetzung für das Testen in der Dev Umgebung war natürlich die genaue Absprache mit dem Auftraggeber. Ich hatte die Freigabe, mehr oder weniger alles in der Dev Umgebung „kaputt“ zu machen, was mir die Arbeit enorm erleichtert hat.

Was von den 20 Findings übrig blieb

Aus den 20 statischen Kandidaten wurden neun verifizierte Findings. Sieben konnte ich an der Dev API dynamisch bestätigen, zwei weitere waren durch Code oder Konfiguration eindeutig belegt. Die restlichen Kandidaten wurden mit ihrem Proof Gap als nicht reproduziert, offen oder nicht ausgeführt dokumentiert. Es konnte vor allem ein Attack Path verifiziert werden, der mehrere gefundene Schwachstellen hintereinander ausnutzt und so innerhalb der App eine Privilege Escalation erreicht hat.

Das Ganze war nicht Plug and Play

Die Verifikation dauerte länger als der Scan. Testaccounts, passende Datensätze und wiederholbare Requests mussten vorbereitet werden. Repository, Xano Export und aktiver Branch konnten außerdem voneinander abweichen. Einige Probes scheiterten mit 400, bevor die eigentlich interessante Autorisierungsprüfung überhaupt erreicht wurde. Auch ein lokaler Mix aus Windows- und WSL-Shell sowie unterschiedliche Zeilenenden in einem Testskript kosteten Zeit.

Das Codex Security Plugin lief während des Reviews zweimal in das damals für meinen Account geltende Fünf-Stunden-Limit von OpenAI. Für die intensive Phase habe ich deshalb ChatGPT Pro (fünf-facher Token Usage) abgeschlossen. In diesem Projekt konnte ich dadurch längere Schritte am Stück abschließen. OpenAI hat dieses Limit im Juli 2026 vorübergehend ausgesetzt und Ende Juli wieder eingeführt. Wer länger am Stück arbeiten will, sollte die aktuelle Regelung also vorher prüfen.

Die Bewertung der verifizierten Findings war teilweise auch nicht trivial, da nur der Auftraggeber einschätzen konnte, ob ein Finding wirklich eine Sicherheitslücke oder nicht doch ein gewolltes Feature war. Bei einem konkreten Fall ging es z.B. darum, wer sich in der App registrieren konnte. Dafür war Domänenwissen wichtig, das konnte ich allein nicht liefern.

Aus den Ergebnissen wird ein Security Review

Für den finalen Report habe ich alle Teile wieder zusammengeführt: Executive Summary, Scope und getesteter Stand, neun verifizierte Findings, Angriffsketten, Fix-Empfehlungen und Retest-Kriterien. Offene Hypothesen bekamen einen eigenen Abschnitt mit der noch fehlenden Evidence. Die bereinigten Requests und Responses lagen separat, damit der Hauptreport lesbar blieb.

Im finalen Finding musste nachvollziehbar sein, welcher User die Eingabe kontrolliert, welcher Schutz fehlte, was ich beobachtet hatte und wie ein Retest aussehen sollte. Severity, Disclosure und Freigabe blieben menschliche Entscheidungen.

Der Fokus beim finalen Report lag auch darauf, dass er AI-lesbar ist, da der Auftraggeber die gefundenen Schwachstellen wiederum im Vibe-Coding Verfahren beheben wollte.

Fazit

Dieses Projekt hat mir gezeigt, wie mächtig Security Tools aktuell schon sind und was bei einem AI-first Ansatz alles beachtet werden muss. Mit einer guten Vorbereitung und schon vorhandenem Fachwissen und Expertise lassen sich Schwachstellen schnell finden, bewerten und verifizieren. Für mich liegt deshalb der größte Nutzen eines AI-first Ansatzes nicht darin, den Pentester zu ersetzen. Er liegt darin, Security Reviews häufiger (idealerweise kontinuierlich) und näher an die Entwicklung zu bringen. Die AI kann Codepfade breit durchsuchen, Hypothesen verfolgen und Tests reproduzierbar vorbereiten. Ob ein Finding belastbar, relevant und verantwortungsvoll zu behandeln ist, bleibt eine menschliche Entscheidung.

Häufige Fragen

Warum reicht der Prompt „Finde Sicherheitslücken“ nicht aus?

Ein offener Prompt liefert keine Kette zwischen Vermutung, Codepfad, Auswirkung und Gegenprobe. Damit lässt sich das Ergebnis nicht in einen belastbaren Bericht überführen. Scope, Angreifermodell, Trust Boundaries und Beleganforderungen gehören in den Auftrag.

Welche Schicht ist im Review die verbindliche Sicherheitsgrenze?

Im beschriebenen Fall war es das Xano-Backend, weil alle Endpunkte öffentlich erreichbar waren. Frontend und Backend for Frontend konnten einen direkten Backend-Aufruf nicht verhindern. Sie blieben relevant für Cross-Site-Scripting, Session-Schutz, Errorhandling, Caching und zusätzliche Rollenprüfungen.

Was unterscheidet Discovery von Validation?

Discovery sucht breit nach verdächtigen Codepfaden. Validation sucht Belege und aktiv Gegenbelege: Gibt es eine Prüfung in einem nachgelagerten Codepfad, ist der Endpunkt im aktiven Branch vorhanden, erreicht der angenommene Angreifer ihn wirklich? Diese Trennung verhindert, dass eine plausible Vermutung immer weiter ausformuliert wird.

Wie viele der statischen Findings haben die Verifikation überstanden?

Aus 20 statischen Kandidaten wurden neun verifizierte Findings. Sieben davon liessen sich dynamisch an der Dev-API bestätigen, zwei über Code oder Konfiguration. Die übrigen wurden mit ihrem Proof Gap als nicht reproduziert, offen oder nicht ausgeführt dokumentiert.

Warum beweist ein HTTP-200 bei einer schreibenden Aktion noch nichts?

Ein 200 sagt nur, dass der Request angenommen wurde. Ob der unerlaubte Zustand wirklich gespeichert wurde, zeigt erst eine anschliessende Zustandsprüfung mit einem berechtigten User als Positivkontrolle. Ein 400 kann umgekehrt auch an ungeeigneten Testdaten liegen.

Lesetipps der Redaktion

LesetippCodex Security: Offener Client füttert OpenAILesetippAPI-Security: der blinde Fleck hinter jeder IntegrationLesetippBug Bounty vs. Pentest: Welches Modell passt zu welchem Unternehmen

Mehr aus dem MBF Media Netzwerk

Digital ChiefsDie KI schreibt den Code. Wer haftet dafür?cloudmagazinClaude Code überholt Copilot im Team-WorkflowMyBusinessFutureDrei Tage Update-Pause: Software-Lieferkette im Blindflug

Bildquelle Titelbild: KI-generiert (August 2026). Grafiken im Beitrag: Mika Schmidt.