Ist es sicher, eine vibe-codierte App zu starten? Eine Sicherheits-Checkliste

Ja, mit einer Einschränkung, die den größten Teil der Antwort entscheidet: Es kommt darauf an, wer den Code deployt. Ein KI-Assistent, der Ihnen einen Ordner voller Dateien übergibt, lässt Ihnen die Server, die Secrets und die Deploy-Pipeline. Eine Plattform, die die Anwendung auf verwalteter Infrastruktur baut und betreibt, nimmt Ihnen mehrere dieser Risiken ab, bevor Sie überhaupt etwas schreiben. Diese Checkliste trennt beides, damit Ihre zwanzig Minuten Prüfung auf die Teile entfallen, die wirklich Ihnen gehören.

Spielt es eine Rolle, welche KI die Anwendung gebaut hat?

Mehr als jeder andere Faktor. Der Bericht 2026 von GitGuardian stellte fest, dass Commits mit KI-Unterstützung mit einer Rate von 3,2 Prozent Secrets preisgaben, gegenüber einem Basiswert von 1,5 Prozent über alle öffentlichen GitHub-Commits hinweg, also rund doppelt so oft. Lesen Sie diese Zahl allerdings genau, denn sie misst Coding-Assistenten: Entwickler, die Code in ihr eigenes Repository generieren und ihn selbst deployen. Es ist ein Befund über eine Arbeitsweise, nicht über KI als solche. Ändern Sie die Arbeitsweise, und die Zahl ändert sich mit, denn eine Plattform, die Ihnen nie einen rohen Schlüssel zum Verlegen in die Hand gibt, beseitigt die Gelegenheit, statt Sie zur Vorsicht zu mahnen.

Ist KI-generierter Code standardmäßig sicher?

Nein, und keine ehrliche Plattform wird Ihnen etwas anderes erzählen. KI schreibt plausiblen Code, nicht zwangsläufig sicheren Code. Sie kann eine Validierung auslassen, Daten offenlegen, die privat bleiben sollten, Zugangsdaten fest im Code hinterlegen, damit eine Funktion läuft, oder ein Paket importieren, das es gar nicht gibt. Behandeln Sie das Ergebnis wie den ersten Entwurf eines schnellen, aber unbeaufsichtigten Junior-Entwicklers: oft gut, gelegentlich gefährlich, immer lesenswert.

Warum liegt KI bei der Sicherheit so oft daneben?

Weil Sicherheitsmängel zur Laufzeit unsichtbar sind. Ein Modell optimiert auf Code, der funktioniert, und „funktioniert“ heißt, dass die Funktion läuft, wenn Sie darauf klicken. Eine fehlende Berechtigungsprüfung wirft keinen Fehler, sie gibt die Daten einfach still zurück. Ein im Klartext gespeichertes Passwort meldet sich einwandfrei an. Ihre Anwendung kann jeden Test bestehen, an den Sie gedacht haben, und trotzdem offen sein. Genau deshalb ist das hier ein Prüfschritt und kein Testschritt.

Welche Risiken nimmt eine verwaltete Plattform weg?

Bauen Sie auf Infrastruktur, die Sie selbst konfigurieren, dann liegt jedes Risiko auf dieser Seite bei Ihnen. Bauen Sie auf einer verwalteten Plattform, dann hören mehrere davon schlicht auf zu existieren, weil es keinen Ort mehr gibt, an dem der Fehler passieren könnte.

• Speicherung von Secrets. Schlüssel, die in einem verschlüsselten Vault liegen und zur Laufzeit eingespielt werden, landen nie in Ihrem Code, wo sie darauf warten, committet zu werden. Modulify arbeitet so, und das ist die wertvollste Voreinstellung von allen, denn geleakte Secrets sind mit Abstand die häufigste Schwachstelle.
• Hosting und HTTPS. Kein Server, den Sie härten müssen, kein Zertifikat, das Sie vergessen können, keine halb konfigurierte Staging-Instanz, die still und leise echte Daten ausliefert. Modulify enthält Hosting, sodass Veröffentlichen nicht bedeutet, Infrastruktur zu konfigurieren.
• Datenbankzugriff. Eine verwaltete Datenbank, die über die Plattform abgefragt wird, arbeitet standardmäßig mit parametrisierten Abfragen, was SQL-Injection ausschließt, ohne dass Sie jede Query prüfen müssen.
• Die Deploy-Pipeline. Es gibt nichts falsch zu konfigurieren, wenn Sie auf Veröffentlichen drücken, statt ein Deployment zu verdrahten.

Das heißt nicht, dass Ihre Anwendung sicher ist, und wer das behauptet, verdient Ihr Misstrauen. Es heißt, dass es weniger Stellen gibt, an denen etwas schiefgehen kann, und das macht die verbleibenden Stellen echter Aufmerksamkeit wert.

Welche Risiken bleiben bei Ihnen?

Diese gehören demjenigen, der die Anwendung gebaut hat, auf jeder Plattform, egal ob ein Mensch oder eine KI den Code geschrieben hat. Das ist die Liste, die zwanzig Minuten wert ist.

1. Zugriffe werden auf dem Server geprüft. Jede Anfrage, die private Daten zurückgibt, prüft erneut, wer sie stellt. Testen Sie es: Melden Sie sich als ein Nutzer an und ändern Sie die Datensatz-ID in der URL auf die eines anderen Nutzers. Werden dessen Daten geladen, haben Sie die häufigste Schwachstelle in Webanwendungen überhaupt. Einen Button auszublenden ist keine Sicherheit.
2. Eingaben werden auf dem Server validiert. Validierung im Client ist eine Bequemlichkeit für Nutzer, keine Verteidigung. Jeder kann eine Anfrage senden, die Ihr Formular komplett umgeht.
3. Sessions liegen in HTTP-only-Cookies. Nicht im Local Storage des Browsers, wo jedes Skript auf der Seite sie lesen und aus einem kleinen Scripting-Fehler eine vollständige Kontoübernahme machen kann.
4. Passwörter werden gehasht. Wenn Ihre Anwendung Passwörter selbst speichert, nehmen Sie bcrypt oder argon2 und nichts Selbstgebautes. Wenn Sie das Passwort eines Nutzers in Ihrer Datenbank lesen können, kann das auch jeder, der eine Kopie davon bekommt.
5. Fehlermeldungen geben keine Details preis. Nutzer sehen eine freundliche Meldung. Stacktraces, Dateipfade und Datenbankfehler bleiben in Ihren Logs, denn für jeden, der Ihre Anwendung abklopft, sind sie eine Landkarte.
6. Alles bereits Offengelegte wird rotiert. Ein Vault schützt Schlüssel ab jetzt, er kann keinen zurückholen, den Sie letzten Monat in einen Chat eingefügt haben. Derselbe Bericht fand heraus, dass über 64 Prozent der 2022 als gültig bestätigten Zugangsdaten 2026 immer noch gültig waren. Eine Offenlegung verfällt also nicht von selbst.
7. Eigener Code und Pakete werden geprüft. In dem Moment, in dem Sie eigenen Code hinzufügen oder eine Bibliothek einbinden, sind Sie wieder selbst mit dem Prüfen dran. Vergewissern Sie sich, dass jedes Paket wirklich existiert und gepflegt wird.

Was sieht der Browser tatsächlich?

Alles, was Sie ihm schicken, und das führt bei Webanwendungen ständig zu Überraschungen, weil die Grenze zwischen Ihrem Code und der Öffentlichkeit nicht dort verläuft, wo man sie vermutet. Jeder Schlüssel, der in clientseitigem JavaScript verwendet wird, ist für jeden sichtbar, der die Entwicklertools öffnet. Ein Aufruf an eine kostenpflichtige API gehört deshalb auf den Server, wo auch der Schlüssel bleibt. Liefern Sie die gesamte Anwendung über HTTPS aus, nicht nur die Login-Seite. Und wenn Sie beim Bauen das Cross-Origin-Sharing aufgeweitet haben, damit etwas funktioniert, ziehen Sie es vor dem Start wieder eng, denn an einem authentifizierten Endpunkt lädt das andere Websites dazu ein, Anfragen im Namen Ihrer angemeldeten Nutzer zu stellen.

Welche Funktionen erhöhen den Einsatz am stärksten?

Drei, und jede verdient zusätzliche Aufmerksamkeit, weil jede einem Fremden einen Hebel in die Hand gibt.

• Datei-Uploads. Validieren Sie Typ und Größe, legen Sie Dateien in einen Object Storage statt neben Ihren Code, und vertrauen Sie nie dem Dateinamen, den Sie bekommen haben.
• Zahlungen. Geben Sie Kartendaten an einen Zahlungsdienstleister und lassen Sie ihn die Daten halten. Ihre Anwendung sollte nie eine Kartennummer zu sehen bekommen.
• Alles, was E-Mails versendet. Setzen Sie ein Rate Limit, sonst wird aus einem offenen Kontaktformular ein Spam-Relay, an dem die Reputation Ihrer Domain hängt.

Was ist Slopsquatting und sollte ich mir Sorgen machen?

Slopsquatting bedeutet, dass Angreifer bösartige Pakete unter Namen veröffentlichen, die KI-Modelle gern halluzinieren, und darauf warten, dass jemand eines davon auf Empfehlung eines Assistenten installiert. Wenn Ihre Anwendung ein von der KI vorgeschlagenes Paket einbindet, prüfen Sie, ob es echt, weit verbreitet und gepflegt ist, bevor Sie ihm vertrauen. Dreißig Sekunden Prüfung verhindern eine Kompromittierung der Lieferkette, die sich später nur sehr schwer wieder auflösen lässt.

Brauche ich für eine einfache Website eine Sicherheitsprüfung?

Eine Marketing-Website ohne Konten und ohne Daten ist risikoarm. Legen Sie los. In dem Moment, in dem Logins, Zahlungen, Datei-Uploads oder personenbezogene Daten dazukommen, arbeiten Sie die Liste ab. Das Risiko wächst mit dem, worauf die Anwendung zugreifen kann, nicht damit, wie sie gebaut wurde. Eine von Hand geschriebene Anwendung mit einer fehlenden Berechtigungsprüfung ist genauso offen wie eine von einer KI geschriebene.

Wie oft sollte ich das durchgehen?

Jedes Mal, wenn Sie etwas hinzufügen, das Daten berührt, und nicht ein einziges Mal vor dem Start. Auf diese Art zu bauen macht Änderungen billig, und das heißt, dass sich die Form Ihrer Anwendung schneller bewegt als Ihr Bild von ihr. Die Liste ist bewusst kurz, damit ein erneuter Durchlauf realistisch bleibt.

Die Sicht von Modulify

Die nützliche Frage war nie, ob man einer KI das Schreiben von Code anvertrauen kann. Sie lautet, welche Risiken Ihr Setup beseitigt und welche es bei Ihnen lässt. Verwaltete Secrets, verwaltetes Hosting und verwaltete Datenbanken streichen eine ganze Fehlerkategorie, bevor Sie anfangen, und Modulify ist bewusst so gebaut. Was keine Plattform übernehmen kann, ist die Entscheidung, wer einen bestimmten Datensatz sehen darf. Dieser Teil bleibt eine kurze Prüfung, die Sie selbst durchführen. Für den größeren Zusammenhang beginnen Sie mit dem, was Vibe Coding wirklich ist, und kombinieren Sie das anschließend mit Vom Prototyp zur Produktion. Bauen Sie auf einer Plattform mit sicheren Voreinstellungen.