Die Sicherheitsrisiken, die in KI-generierten Apps stecken

Eine vibe-codierte App kann vor Ihren Augen einwandfrei laufen und darunter trotzdem völlig offen sein. Das ist der unangenehme Teil der KI-App-Generierung: Die Demo funktioniert, der Kunde ist beeindruckt, und nichts davon sagt Ihnen, ob sich der Login-Bildschirm umgehen lässt oder die Datenbank für jeden offenliegt, der eine Netzwerkanfrage untersucht.

KI-Modelle werden darauf trainiert, etwas Fertig-Aussehendes zu produzieren. Sie werden nicht darauf trainiert zu fragen, „wer sonst könnte diesen Endpunkt erreichen“. Genau in dieser Lücke steckt der größte Teil des echten Risikos in KI-generierter Software, und sie fällt selten auf, bevor jemand gezielt danach sucht.

Die Zahlen sind schlechter, als die meisten Builder annehmen

Unabhängige Forschung zu LLM-generiertem Code bestätigt das mit einer konkreten, unbequemen Zahl: Modelle kompilieren in etwa 90 % der Fälle erfolgreich funktionierenden Code, aber rund 45 % dieses Codes enthalten mindestens eine OWASP-Top-10-Schwachstelle, etwa umgehbare Login-Prüfungen oder Injection-Lücken, mit denen ein Angreifer eine Abfrage manipulieren kann.

Das ist kein seltener Ausnahmefall. Es bedeutet, dass fast die Hälfte dessen, was ein Tool wie Lovable, Bolt oder Base44 bei einem gegebenen Prompt für Sie generiert, von Anfang an eine echte, ausnutzbare Schwachstelle enthält. Die App „funktioniert“ dabei nach außen weiterhin einwandfrei. Die Schwachstelle meldet sich einfach nicht, bis ein Nutzer (oder Angreifer) sie findet.

Woher das Risiko wirklich kommt

Sicherheitsprobleme in KI-generierten Apps häufen sich um eine Handvoll wiederkehrender Muster:

• Clientseitige Authentifizierungsprüfungen. Die KI implementiert „darf dieser Nutzer diese Seite sehen“ im Browser statt auf dem Server. Da Browser-Code vollständig sichtbar und veränderbar ist, kann jeder die Entwicklertools öffnen, die Prüfung umdrehen und sich Zugang verschaffen.
• Fest codierte Geheimnisse. Nicht-technische Builder, die lokal testen, wissen oft nicht, wie man .env-Dateien richtig verwaltet, sodass API-Schlüssel und Datenbank-Verbindungsstrings direkt in den Code getippt werden. Diese Dateien landen dann unbemerkt in einem öffentlichen GitHub-Repo.
• Zu freizügige Datenbankregeln. Um einen Prompt schnell zum Laufen zu bringen, konfiguriert die KI den Datenbankzugriff breit statt eng. Wird ein anderer Teil der App kompromittiert, verwandelt diese offene Konfiguration einen kleinen Fehler in ein vollständiges Datenleck.
• Zu weit gefasste OAuth-Verbindungen. Beim Einrichten einer Integration wie Google Calendar oder Slack müssen OAuth-Scopes manuell konfiguriert werden. Fordert man zu viel Zugriff an, entsteht eine Haftungsfrage; vergisst man einen Scope, bricht die Integration still. So oder so trifft der Builder eine Sicherheitsentscheidung, die ihm meist gar nicht bewusst ist.

Nichts davon zeigt sich in einer Demo. Es zeigt sich bei einem Sicherheitsaudit, in der Browserkonsole eines neugierigen Nutzers oder Monate später in einer Datenschutzverletzungsmeldung.

Warum „es funktioniert“ der falsche Test ist

Die Falle ist, dass KI-App-Builder schnelles Ausliefern belohnen, und schnelle Feedback-Schleifen trainieren einen darauf, nur den Idealpfad zu testen. Man klickt sich durch den Registrierungsflow, das Dashboard lädt, das Formular wird abgeschickt, alles sieht richtig aus. Nichts davon sagt Ihnen, ob die CRUD-Aktion hinter diesem Formular prüft, wer die Anfrage stellt.

Sicherheit richtig zu testen bedeutet, andere Fragen zu stellen:

1. Kann ein ausgeloggter Nutzer diese URL direkt erreichen?
2. Kann Nutzer A die Datensätze von Nutzer B sehen oder bearbeiten, indem er eine ID in der Adressleiste ändert?
3. Werden Rollenprüfungen auf dem Server durchgesetzt, oder nur in der Oberfläche versteckt?
4. Fordern OAuth-verbundene Integrationen nur die Scopes an, die sie tatsächlich nutzen?

Die meisten nicht-technischen Builder wissen nicht, dass sie diese Fragen stellen sollten, und die meisten KI-Coding-Assistenten sprechen sie nicht von sich aus an, sofern man nicht ausdrücklich sagt „prüfe das auf Sicherheitsprobleme“, und selbst dann ist die Lösung nur ein weiterer generierter Patch, keine strukturelle Garantie.

Die Alternative: Infrastruktur, die man nicht auditieren muss

Das ist das eigentliche Argument dafür, Business-Apps auf einer Plattform zu bauen, bei der Sicherheit von Grund auf eingebaut ist, statt pro Projekt neu generiert zu werden. Softr ist ein gutes Beispiel für den umgekehrten Ansatz: Authentifizierung, Rollenberechtigungen und Datenzugriffsregeln sind native Plattformfunktionen, kein Code, den die KI für jede App neu schreibt.

Konkret bedeutet das:

• Serverseitiges CRUD standardmäßig. Lese-/Schreibaktionen auf der Datenbank laufen auf Softrs Servern, nicht im Browser, sodass es von vornherein keine clientseitige Prüfung zum Umgehen gibt.
• Visuelle Rollenberechtigungen statt handgeschriebenem RLS. Nutzergruppen und Datenbeschränkungen steuern, wer welche Datensätze sieht und bearbeitet, visuell konfiguriert und über Vorschau-Impersonation überprüft, statt in leicht falsch konfigurierbarem Datenbank-Policy-Code vergraben zu sein.
• Vorab geprüfte OAuth-Connectoren. Integrationen mit Tools wie Google Calendar, HubSpot und Stripe nutzen Softrs bereits genehmigte Entwickleranwendungen, sodass Builder nie mit rohen OAuth-Scopes hantieren oder selbst Drittanbieter-Zugangsdaten speichern müssen.
• Fertige Authentifizierungs-Flows out of the box. Login, Passwort-Reset, OTP und domänenbeschränkte Registrierung sind vorgefertigt, sodass es keine individuelle Authentifizierungslogik gibt, die eine KI subtil falsch bauen könnte.

Das heißt nicht, dass KI-generierte Tools für alles ungeeignet sind. Für ein persönliches Projekt, einen internen Prototyp, den niemand außerhalb des eigenen Teams anfasst, oder eine statische Landingpage ist das Risikoprofil gering, und Vibe Coding ist hier tatsächlich der schnellere Weg. Die Rechnung ändert sich in dem Moment, in dem echte Nutzer, echte Kundendaten oder externe Logins ins Spiel kommen.

Was Sie vor dem Launch prüfen sollten

Wer trotzdem mit einem codegenerierenden KI-Tool baut, für den ist eine kurze Liste besser als keine:

• Durchsuchen Sie die Codebasis vor jedem Commit per Grep nach fest codierten API-Schlüsseln und Verbindungsstrings.
• Stellen Sie sicher, dass Zugriffskontrollen auch serverseitig dupliziert sind und nicht nur im Frontend versteckt.
• Überprüfen Sie die OAuth-Scopes jeder verbundenen Integration und entfernen Sie alles Ungenutzte.
• Bitten Sie eine zweite Person, idealerweise mit technischem Hintergrund, zu versuchen, durch Erraten oder Ändern einer ID in der URL auf die Daten eines anderen Nutzers zuzugreifen.

Diese Checkliste macht generierten Code nicht so sicher wie eine Infrastruktur, die nie generiert wurde, aber sie fängt die häufigsten Fehler ab. Für ein Portal, ein CRM oder ein internes Tool, in das sich echte Menschen mit echten Daten einloggen, ist die dauerhaftere Lösung, ein Fundament zu wählen, bei dem die Sicherheitsarbeit bereits erledigt wurde, damit es nicht bei jedem Prompt Zufall ist.