Vibe Coding und Sicherheit: die berechtigte Kritik
Der häufigste Einwand gegen Vibe Coding ist ein guter: Wenn niemand den Code liest, sieht auch niemand die Lücke darin. Das ist kein Argument gegen die Methode, sondern eines für einen bewussten Umgang mit ihr — und für eine klare Grenze zwischen internem Werkzeug und öffentlich erreichbarer Anwendung.
Kurz gesagt
Beim Vibe Coding entsteht Code, den niemand Zeile für Zeile prüft. Für interne Werkzeuge mit begrenztem Nutzerkreis ist das Risiko überschaubar. Für öffentlich erreichbare Anwendungen mit personenbezogenen Daten sollte eine fachliche Prüfung dazukommen — und einige Grundregeln gelten unabhängig davon, wer den Code geschrieben hat.
Was tatsächlich schiefgeht — und was nicht
Die Kritik ist berechtigt, aber ungenau formuliert
Der Einwand lautet meist: "Niemand liest den Code, also sieht niemand die Lücke." Das stimmt — trifft aber ebenso auf jede eingekaufte Standardsoftware zu, deren Quellcode gar nicht einsehbar ist. Der Unterschied ist nicht das Lesen, sondern wer die Verantwortung trägt und ob überhaupt jemand geprüft hat.
Nützlicher ist die Frage nach dem Schadensfall: Wer kann die Anwendung erreichen, welche Daten liegen darin, und was passiert im schlimmsten Fall. Ein internes Werkzeug für acht Personen und ein öffentliches Portal mit Gesundheitsdaten sind zwei völlig verschiedene Risiken — mit derselben Bauweise.
Die vier Fehler, die tatsächlich auftreten
Aus der Praxis wiederholen sich vier Muster: eine Anwendung ohne Anmeldung öffentlich erreichbar; Zugangsdaten im Klartext oder im Quelltext hinterlegt; fehlende Prüfung, ob der angemeldete Nutzer den angefragten Datensatz überhaupt sehen darf; und Eingaben, die ungefiltert in eine Datenbankabfrage wandern.
Keiner dieser Fehler ist spezifisch für KI-erzeugten Code — sie stehen seit Jahren in der OWASP-Liste der häufigsten Schwachstellen. Neu ist nur, dass sie jetzt auch Menschen unterlaufen, die vorher gar keine Software gebaut hätten.
Rechteprüfung ist die Lücke mit der größten Wirkung
Die schwerste und unauffälligste Klasse ist die fehlende Objektprüfung: Die Anmeldung funktioniert, die Oberfläche zeigt nur die eigenen Datensätze — aber wer die Adresszeile von Datensatz 41 auf 42 ändert, sieht die Daten eines anderen Kunden. Im Betrieb fällt das nie auf, weil niemand es probiert.
Diese Prüfung gehört in die Anwendung und nicht in die Oberfläche. Sie ist der Grund, warum ein Datenmodell mit Zuständigkeiten von Anfang an gebaut werden sollte, statt Rechte nachträglich über die Ansicht zu regeln.
Ein Maßstab, der zum Einsatz passt
Für ein internes Werkzeug ohne personenbezogene Daten reichen Anmeldung, Rechte je Rolle und eine Sicherung. Sobald personenbezogene Daten dazukommen, gehören Protokollierung der Zugriffe, technisch umgesetzte Löschfristen und ein Auftragsverarbeitungsvertrag dazu — Letzterer ist keine technische, sondern eine vertragliche Frage.
Für alles, was öffentlich erreichbar ist und besondere Datenkategorien nach Art. 9 DSGVO verarbeitet — Gesundheit, Religion, Gewerkschaftszugehörigkeit — ist eine fachliche Prüfung vor dem Livegang die richtige Antwort, unabhängig davon, wie der Code entstanden ist.
Sicherheit als Teil der Beschreibung
Vieles lässt sich vorab festlegen, statt es hinterher zu prüfen.
Bau eine Anwendung für unser Beschwerdemanagement und berücksichtige dabei die Sicherheit. Beschwerden enthalten Namen und Kontaktdaten von Kunden. Zugriff haben nur angemeldete Mitarbeitende, und jede Anzeige einer Beschwerde wird protokolliert. Anhänge dürfen nur bestimmte Dateitypen sein und maximal zehn Megabyte groß. Nach Abschluss werden Beschwerden nach drei Jahren gelöscht. Die Anwendung soll bei fünf fehlgeschlagenen Anmeldeversuchen den Zugang zeitweise sperren.
Welche Sicherheitsentscheidungen daraus folgen
zugriff
|
nur angemeldete nutzer, keine oeffentliche einsicht |
protokoll
|
jede anzeige einer beschwerde wird mit nutzer und zeitpunkt festgehalten |
uploads
|
nur erlaubte dateitypen, groessenbegrenzung, keine ausfuehrbaren dateien |
anmeldung
|
sperre nach 5 fehlversuchen, passwoerter nur als hash gespeichert |
loeschung
|
drei jahre nach abschluss automatisch |
transport
|
verschluesselte verbindung, daten in deutschland |
Die Grundregeln, unabhängig vom Werkzeug
Zugriff beschränken
Jede Anwendung braucht personengebundene Zugänge und Rollen. „Alle sehen alles" ist der häufigste Fehler und der folgenreichste.
Passwörter niemals im Klartext
Sie gehören als Hash gespeichert. Wenn eine Anwendung ein Passwort per Mail zurücksenden kann, ist etwas grundsätzlich falsch.
Eingaben nicht vertrauen
Alles, was ein Nutzer eingeben kann, muss geprüft werden — besonders bei Datei-Uploads und Suchfeldern.
Protokollieren, wer was gesehen hat
Bei personenbezogenen Daten ist das nicht nur Sicherheit, sondern auch eine Anforderung aus der Rechenschaftspflicht der DSGVO.
Löschfristen technisch umsetzen
Daten, die nicht mehr da sind, können nicht abfließen. Das ist die wirksamste und am häufigsten übersehene Maßnahme.
Vor dem Livegang prüfen lassen
Bei öffentlich erreichbaren Anwendungen mit sensiblen Daten gehört eine fachliche Sicherheitsprüfung dazu — unabhängig davon, wer den Code geschrieben hat.
Risiko nach Anwendungsart
| Internes Werkzeug | Anwendung mit Kundendaten | Öffentlich erreichbar | |
|---|---|---|---|
| Nutzerkreis | Bekannte Mitarbeitende | Mitarbeitende und Kunden | Unbekannt |
| Typisches Risiko | Fehlbedienung | Datenschutzverstoß | Angriff von außen |
| Mindestens nötig | Rollen und Protokoll | Zusätzlich Löschkonzept | Zusätzlich fachliche Prüfung |
| Fachliche Prüfung | Empfohlen | Dringend empfohlen | Notwendig |
| Vibe Coding geeignet | Ja | Ja, mit Sorgfalt | Nur mit Prüfung |
Marktübersicht und Einschätzungen mit Stand: 29.08.2026. Funktionsumfang und Preise der genannten Werkzeuge ändern sich häufig — prüft den aktuellen Stand beim jeweiligen Anbieter.
Sicherheit in drei Stufen
Einordnen: intern, extern oder sensible Daten
Grundregeln prüfen: Zugriff, Daten, Protokoll
Bei erhöhtem Risiko fachlich prüfen lassen
Häufig gestellte Fragen
-
Ist Vibe Coding unsicher?
Nicht grundsätzlich. Das Risiko hängt davon ab, wer auf die Anwendung zugreifen kann und welche Daten sie verarbeitet. Ein internes Werkzeug für zehn Kolleginnen ist etwas anderes als eine öffentlich erreichbare Anwendung.
- Wer haftet, wenn etwas passiert?
- Brauchen wir eine Sicherheitsprüfung?
- Was ist die häufigste Schwachstelle?
- Müssen wir eine Datenschutz-Folgenabschätzung machen?
- Gilt das auch in Österreich und der Schweiz?
- Was ist mit Meldepflichten bei einer Panne?
- Ist das hier eine Rechts- oder Sicherheitsberatung?
Das könnte dich auch interessieren
Bau sicher, von Anfang an
Beschreib die Sicherheitsanforderungen mit, statt sie nachzurüsten.
