KI-generierte Apps sicher in die Cloud deployen: Was Unternehmen beachten müssen

Vibe-Code-App produktionsreif machen - WZ-IT prüft, härtet und betreibt KI-generierte Anwendungen: Security-Audit, sauberes Deployment und Managed Operations auf souveräner Infrastruktur. Kostenlosen Termin vereinbaren

KI-Tools wie Lovable, Bolt, v0, Replit oder Cursor haben die Softwareentwicklung verändert. Aus einer Idee wird in Stunden eine lauffähige App, oft ohne dass eine Zeile von Hand geschrieben wurde. Die Demo läuft, das Login funktioniert, die Datenbank ist angebunden. Der Reflex ist verständlich: schnell deployen und live gehen.

Genau hier liegt das Problem. Eine lauffähige Demo ist kein produktionsreifes System. KI-Modelle optimieren auf Code, der funktioniert, nicht auf Code, der sicher ist. Eine Untersuchung von Veracode aus 2025 fand, dass rund 45 Prozent des von über 100 Sprachmodellen erzeugten Codes Sicherheitslücken aus der OWASP-Top-10-Klasse enthielt, und dass neuere oder größere Modelle dabei nicht besser abschnitten (Veracode GenAI Code Security Report). Das Risiko ist also kein Übergangsphänomen, sondern strukturell.

Dieser Beitrag umreißt, worauf Unternehmen achten müssen, wenn sie eine KI-generierte App sicher in die Cloud bringen wollen: von der Zugriffskontrolle über Secrets und Datenbank bis zur Deployment-Härtung und DSGVO.

Inhaltsverzeichnis

• Warum KI-Code ein Sicherheitsrisiko ist
• Authentifizierung und Zugriffskontrolle
• Secrets und API-Keys
• Datenbank: das Supabase-RLS-Problem
• Abhängigkeiten und Supply Chain
• Deployment härten
• DSGVO und Datenstandort
• Vor dem Go-live: die Checkliste
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Quellen

Warum KI-Code ein Sicherheitsrisiko ist

Das Kernproblem ist nicht, dass KI schlechten Code schreibt. Sie schreibt plausiblen Code, der die gewünschte Funktion erfüllt. Was sie systematisch unterschätzt, sind die Dinge, die in der Demo nicht auffallen: Was passiert, wenn ein Angreifer die API direkt anspricht? Was, wenn jemand die Nutzer-ID in der Anfrage manipuliert? Was, wenn eine Eingabe nicht das ist, was das Formular erwartet?

Die genannte Veracode-Auswertung zeigt das Muster deutlich: Bei manchen Schwachstellenklassen wie Cross-Site-Scripting lag die Fehlerquote über 80 Prozent. Hinzu kommt ein zweites Risiko, das viele unterschätzen: Wer eine App vollständig generieren lässt, versteht oft selbst nicht im Detail, was im Code passiert. Damit fehlt die Grundlage, um Sicherheitslücken überhaupt zu erkennen.

Für Unternehmen heißt das: Eine KI-generierte App ist ein hervorragender Ausgangspunkt, aber sie gehört vor dem Produktivgang auf den Prüfstand. Die folgenden Abschnitte sind die Bereiche, in denen die meisten Probleme stecken.

Authentifizierung und Zugriffskontrolle

In den OWASP Top 10 steht Broken Access Control auf Platz eins. Genau hier scheitern KI-generierte Apps am häufigsten. Typische Muster:

• Die Oberfläche blendet einen Button aus, aber die zugrundeliegende API prüft die Berechtigung nicht. Wer den API-Endpunkt direkt aufruft, kommt trotzdem durch.
• Ein Nutzer kann durch Ändern einer ID in der Anfrage die Daten anderer Nutzer abrufen.
• Admin-Funktionen sind nicht serverseitig abgesichert, sondern nur im Frontend versteckt.

Die Regel lautet: Zugriffskontrolle gehört immer auf den Server, niemals nur ins Frontend. Jeder Endpunkt muss prüfen, ob der angemeldete Nutzer die angeforderte Aktion ausführen darf. KI-generierter Code setzt das oft nur halb um, weil die Demo auch ohne vollständige Prüfung funktioniert.

Secrets und API-Keys

Der zweite Klassiker sind Zugangsdaten an der falschen Stelle. KI-Tools legen API-Keys, Datenbank-Passwörter oder Tokens gerne dort ab, wo sie gerade gebraucht werden, und das ist häufig der Frontend-Code oder eine Konfigurationsdatei, die im Repository landet.

Alles, was im Browser ankommt, ist öffentlich. Ein API-Key im Frontend-Bundle lässt sich mit den Entwickler-Tools auslesen. Ein Secret, das einmal in die Git-Historie eingecheckt wurde, bleibt dort, auch wenn die nächste Version es entfernt. Die Grundsätze:

• Secrets gehören in serverseitige Umgebungsvariablen, nie ins Frontend und nie ins Repository.
• Öffentliche und geheime Schlüssel klar trennen. Bei Diensten wie Supabase ist der anon-Key bewusst öffentlich, der service-role-Key dagegen streng geheim.
• Versehentlich exponierte Schlüssel werden rotiert, nicht nur gelöscht.

Datenbank: das Supabase-RLS-Problem

Viele KI-generierte Apps nutzen Supabase oder einen ähnlichen Backend-as-a-Service-Dienst, weil sich damit schnell ein Datenbank-Backend anbinden lässt. Das ist praktisch, hat aber eine scharfe Kante: Row Level Security (RLS).

RLS regelt pro Datenzeile, wer was lesen oder schreiben darf. Laut Supabase-Dokumentation muss RLS für jede Tabelle im öffentlichen Schema aktiviert sein. Der Haken: Tabellen, die über die grafische Tabellen-Oberfläche angelegt werden, haben RLS standardmäßig aktiviert, Tabellen, die per SQL erstellt werden, jedoch nicht. Und genau das macht KI-generierter Code gern, ohne die Policies zu setzen.

Die Folge ist drastisch: Ohne aktivierte RLS hat jeder, der den öffentlichen anon-Key kennt, vollen Lese- und Schreibzugriff auf die betroffenen Tabellen. Der anon-Key steckt im Frontend, ist also für jeden sichtbar. Eine vibe-codete App mit deaktivierter RLS ist damit faktisch eine offene Datenbank im Internet. Vor jedem Go-live gilt deshalb: RLS auf allen Tabellen prüfen, Policies schreiben, mit verschiedenen Nutzerrollen testen.

Abhängigkeiten und Supply Chain

KI-generierter Code bringt fremde Pakete mit, und hier entsteht ein neues Risiko. Sprachmodelle schlagen gelegentlich Paketnamen vor, die es gar nicht gibt. Angreifer nutzen das aus, indem sie diese halluzinierten Namen vorab in npm, PyPI und anderen Registries registrieren und mit Schadcode füllen. Das Muster hat einen Namen: Slopsquatting.

Eine auf der USENIX Security 2025 vorgestellte Studie analysierte 2,23 Millionen Code-Beispiele und fand, dass Open-Source-Modelle bei rund 21,7 Prozent der Fälle nicht existierende Pakete erfanden, kommerzielle Modelle bei rund 5,2 Prozent. Besonders kritisch: 43 Prozent dieser halluzinierten Namen tauchten bei wiederholten Anfragen immer wieder auf, sind also vorhersehbar und damit gezielt angreifbar (Snyk: Slopsquatting).

Dazu kommt das übliche Problem veralteter Pakete mit bekannten Schwachstellen. Beides adressiert man gleich: Dependencies vor dem Deployment gegen die offiziellen Registries und gegen bekannte CVEs prüfen, und im Betrieb ein laufendes CVE-Monitoring etablieren, das nicht nach vier Wochen veraltet.

Deployment härten

Selbst wenn der Anwendungscode sauber ist, entscheidet die Deployment-Umgebung über die Sicherheit. Die wichtigsten Punkte:

• TLS überall. Kein produktiver Dienst läuft ohne Verschlüsselung. Ein Reverse Proxy mit automatischen Zertifikaten ist Standard.
• Rate-Limiting. Ohne Begrenzung sind Login-Endpunkte und teure API-Aufrufe offen für Missbrauch und Brute-Force.
• CORS und Security-Header sauber setzen. Korrekte Origin-Beschränkungen und Header wie Content-Security-Policy verhindern eine ganze Klasse von Angriffen.
• Keine offenen Admin- oder Debug-Endpunkte. Was in der Entwicklung praktisch war, darf in Produktion nicht erreichbar sein.
• Logging und Monitoring. Ohne Protokollierung merkt niemand, dass etwas passiert. Security Logging and Monitoring Failures sind ein eigener Punkt in den OWASP Top 10.

Wer eine App self-hosted betreiben will, findet in Coolify eine souveräne Deployment-Plattform, die TLS, Reverse Proxy und Datenbank-Provisioning aus einer Hand bereitstellt. Wie man eine App damit sauber aufsetzt, zeigt unser Beitrag zu Coolify v4.0.0.

DSGVO und Datenstandort

Beim Cloud-Deployment kommt eine Ebene dazu, die rein technische Checklisten oft auslassen: der Datenschutz. Viele KI-Tools deployen standardmäßig auf US-Plattformen. Sobald personenbezogene Daten verarbeitet werden, ist das ein Thema.

Ein Datenstandort in der EU ist die Grundvoraussetzung, aber allein nicht ausreichend. Dazu gehören die Auftragsverarbeitung, eine saubere Zugriffskontrolle, die Protokollierung und der Ausschluss von Drittland-Zugriffen. Eine App auf europäischer Infrastruktur vereinfacht die datenschutzrechtliche Bewertung erheblich gegenüber US-Plattformen, die dem CLOUD Act unterliegen. Wer hier auf Nummer sicher gehen will, plant das Deployment von Anfang an mit Blick auf DSGVO-Compliance und Datensouveränität.

Vor dem Go-live: die Checkliste

Bevor eine KI-generierte App live geht, sollten diese Punkte geprüft sein. Ein strukturierter, unabhängiger Review deckt genau die Lücken auf, die im Eigenbau übersehen werden (Quelle):

1. Zugriffskontrolle serverseitig für jeden Endpunkt geprüft.
2. Secrets aus Frontend und Repository entfernt, exponierte Schlüssel rotiert.
3. Row Level Security auf allen Datenbank-Tabellen aktiviert und mit mehreren Rollen getestet.
4. Eingaben serverseitig validiert, nicht nur im Formular.
5. Dependencies gegen bekannte CVEs und auf existierende Paketnamen geprüft.
6. Deployment gehärtet: TLS, Rate-Limiting, CORS, Security-Header, keine offenen Admin-Endpunkte.
7. Logging und Monitoring aktiv, CVE-Monitoring für den laufenden Betrieb eingerichtet.
8. Datenstandort und DSGVO geklärt.

Unser Vorgehen bei WZ-IT

Eine KI-generierte App ist ein guter Startpunkt, aber der Weg von der Demo zum belastbaren Produktivsystem ist Handarbeit. So gehen wir vor:

1. Audit. Wir prüfen die App auf die genannten Punkte: Zugriffskontrolle, Secrets, RLS, Validierung, Dependencies und Deployment. Das Ergebnis ist eine konkrete Liste mit Prioritäten.

2. Härtung. Wir schließen die gefundenen Lücken, trennen Secrets sauber, setzen RLS und serverseitige Validierung, aktualisieren Abhängigkeiten und härten die Umgebung.

3. Souveränes Deployment. Wir bringen die App auf europäische Infrastruktur, mit TLS, Reverse Proxy, Backups und Monitoring. Ob self-hosted auf Coolify oder in einem betreuten Setup.

4. Managed Operations. Updates, Patch-Management und CVE-Monitoring im laufenden Betrieb, damit die App auch in einem halben Jahr noch sicher ist.

Den ganzen Weg von der Vibe-Code-App zur Produktion bündeln wir in unserer Prototype-to-Production-Begleitung, ergänzt um KI-Softwareentwicklung für alles, was darüber hinausgeht.

Weiterführende Guides

• Lovable vs Bolt vs v0: Ehrlicher Vergleich 2026 - welches KI-Tool wofür
• Coolify v4.0.0: Souveräne Deployment-Plattform - die App sauber deployen
• OpenClaw sicher deployen: Security-Hardening-Guide - Härtung am konkreten Beispiel
• CVE-Monitoring für self-hosted Software - warum Patch-Management Pflicht ist
• Prototype to Production bei WZ-IT - Vibe-Code-Apps produktionsreif machen

KI-App gebaut, aber unsicher beim Go-live? Wir prüfen Zugriffskontrolle, Secrets, RLS und Deployment, härten die App und betreiben sie souverän auf europäischer Infrastruktur. Erstgespräch vereinbaren

Stand: Juni 2026. Dieser Beitrag ist kein Rechtsrat. Bei konkreten Datenschutz- und Compliance-Fragen Datenschutz- und Rechtsberatung hinzuziehen.

Quellen

• Veracode: GenAI Code Security Report 2025
• OWASP Top 10
• OWASP Top 10 for LLM Applications 2025
• Supabase: Row Level Security
• Supabase: Securing your API
• Snyk: Slopsquatting und KI-halluzinierte Pakete
• Cloud Security Alliance: Slopsquatting und KI-Supply-Chain
• KI-App vor dem Deployment prüfen lassen