Zurück zum Blog
Vibe Coding produziert 45 % unsicheren Code: Der Kater ist da

Vibe Coding produziert 45 % unsicheren Code: Der Kater ist da

Dennis Reinkober13. März 20264 Min. Lesezeit

„Vibe Coding" wurde zum Collins-Wort des Jahres 2025 gewählt. Die Idee klingt verlockend: beschreibe, was du willst, lass die KI den Code schreiben, schau nicht so genau hin. Einfach shippen.

Wir nutzen KI jeden Tag. Wir haben darüber geschrieben. Aber nach einem Jahr Review von KI-generiertem Code in Produktions-Codebases müssen wir über das sprechen, was tatsächlich in diesem Code steckt — denn 45 % davon fällt bei grundlegenden Security-Tests durch.

Die Zahlen sind hässlich

Veracodes State of Software Security Report 2025 zeigt: 45 % des KI-generierten Codes enthält Sicherheitslücken. Keine Style-Probleme. Keine Lint-Warnungen. Echte, ausnutzbare Schwachstellen.

Hier ist, was wir am häufigsten sehen:

SchwachstelleHäufigkeitSchweregrad
Fehlende Input-ValidierungSehr häufigMittel–Hoch
SQL/NoSQL InjectionHäufigKritisch
Fehlende Authentifizierungs-ChecksHäufigKritisch
Hardcodierte Secrets in BeispielenGelegentlichKritisch
Path Traversal bei DateioperationenGelegentlichHoch
Fehlendes Rate LimitingSehr häufigMittel

Das sind keine theoretischen Szenarien. Wir haben jede einzelne dieser Schwachstellen in KI-generiertem Code bei echten Kundenprojekten gefunden.

Wie KI-generierte Schwachstellen tatsächlich aussehen

1. Der fehlende Auth-Check

Das ist das gefährlichste Muster, weil es komplett korrekt aussieht:

// KI-generiert: sauber, typisiert, funktioniert perfekt
export async function GET(
  request: NextRequest,
  { params }: { params: { id: string } }
) {
  const order = await prisma.order.findUnique({
    where: { id: params.id },
    include: { items: true, customer: true },
  });

  if (!order) {
    return NextResponse.json({ error: "Not found" }, { status: 404 });
  }

  return NextResponse.json(order);
}

Siehst du das Problem? Keine Authentifizierung. Keine Autorisierung. Jeder kann jede Bestellung per ID abrufen — inklusive Bestellungen anderer Kunden mit deren persönlichen Daten. Die KI hat einen perfekt funktionierenden Endpoint generiert, der ein DSGVO-Verstoß auf Abruf ist.

// Was es sein sollte:
export async function GET(
  request: NextRequest,
  { params }: { params: { id: string } }
) {
  const session = await auth();
  if (!session?.user) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const order = await prisma.order.findUnique({
    where: { id: params.id, userId: session.user.id },
    include: { items: true },
  });

  if (!order) {
    return NextResponse.json({ error: "Not found" }, { status: 404 });
  }

  return NextResponse.json(order);
}
Realer Vorfall

Wir haben genau dieses Muster bei einem Kunden-Review gefunden. Die KI hatte 14 API-Routes generiert. Drei davon hatten keine Auth-Checks. Eine leakte E-Mail-Adressen von Kunden. Das war in einem PR, der auf den ersten Blick „gut aussah."

2. Die selbstsichere SQL Injection

KI-Modelle haben genug gelernt, um String-Konkatenation + SQL meistens zu vermeiden. Aber sie produzieren immer noch subtile Injection-Vektoren:

// KI-generiert: nutzt Template Literals für „Komfort"
export async function searchProducts(query: string) {
  const products = await prisma.$queryRaw`
    SELECT * FROM products
    WHERE name ILIKE '%${query}%'
    ORDER BY created_at DESC
  `;
  return products;
}

Das sieht aus, als würde es Prismas Tagged Template nutzen, aber das ${query} innerhalb des ILIKE-Patterns umgeht die Parametrisierung.

3. Die geschwätzige Response

// KI-generiert: gibt das volle User-Objekt zurück
const user = await prisma.user.findUnique({ where: { id } });
return NextResponse.json(user);
// Enthält: passwordHash, resetToken, internalNotes, stripeCustomerId

KI gibt standardmäßig alles zurück. Sie weiß nicht, welche Felder sensibel sind, weil sie deinen Business-Kontext nicht versteht. Ein select-Clause ist nicht optional — es ist eine Sicherheitsgrenze.

Warum Vibe Coding das Problem verschärft

Traditionelle KI-unterstützte Entwicklung hat einen Menschen, der jede generierte Zeile liest. Vibe Coding verhindert das explizit. „Lies den Code nicht, schau einfach, ob er funktioniert." Das erzeugt drei sich verstärkende Probleme:

  1. Kein Review-Filter. Schwachstellen, die ein Entwickler im normalen PR-Flow fangen würde, gehen direkt durch.
  2. Falsches Vertrauen. Der Code funktioniert im Happy Path, also muss er in Ordnung sein. Security-Fehler zeigen sich selten in manuellen Tests.
  3. Volumen. Vibe Coding produziert mehr Code schneller. Mehr Code = mehr Angriffsfläche = mehr Verstecke für Schwachstellen.
Die Mathematik

Wenn KI 100 Funktionen generiert und 45 % Security-Probleme haben, sind das 45 verwundbare Endpoints. Ein Mensch, der diese 100 Funktionen über Wochen schreibt, würde die meisten Probleme beim Schreiben selbst finden. Geschwindigkeit ohne Review ist nur schnellere Schwachstellen-Produktion.

Unsere KI-Code-Review-Checkliste

Nachdem wir zu viele Probleme in KI-generiertem Code gefunden haben, haben wir eine Review-Checkliste erstellt. Jeder KI-generierte PR wird dagegen geprüft, bevor er gemergt werden kann:

Authentifizierung & Autorisierung

  • Jeder Endpoint prüft Authentifizierung
  • Daten sind auf den authentifizierten User beschränkt (kein IDOR)
  • Admin-Only-Routes haben Rollen-Checks
  • API-Keys sind nirgends hardcodiert

Input-Validierung

  • Alle User-Inputs werden validiert und sanitized
  • File-Uploads prüfen Typ, Größe und Inhalt
  • Query-Parameter werden mit Zod oder Äquivalent geparst
  • Kein Raw-SQL mit String-Interpolation

Daten-Exposition

  • Response-Objekte nutzen select — niemals volle Models zurückgeben
  • Fehlermeldungen leaken keine internen Details
  • Logs enthalten keine PII oder Secrets
  • Stack Traces sind in Production versteckt

Business Logic

  • Edge Cases sind behandelt (leere Arrays, Null-Werte, Concurrent Access)
  • Rate Limiting ist auf öffentliche Endpoints angewandt
  • Geldbeträge nutzen Decimal, nicht float
  • Statusübergänge sind validiert

Infrastruktur

  • Umgebungsvariablen werden für Konfiguration verwendet
  • CORS ist explizit konfiguriert, nicht *
  • Sensible Headers sind gesetzt (CSP, HSTS, X-Frame-Options)
  • Dependencies sind gepinnt und auditiert

Wo KI-generierter Code sicher ist

Wir sagen nicht „nutzt keine KI." Wir nutzen sie täglich. Aber wir haben gelernt, welche Aufgaben man delegieren kann und welche nicht:

Sicher für KIBraucht Human ReviewNiemals delegieren
UI-KomponentenAPI-RoutesAuth-Logik
Prisma-SchemasDatenbank-QueriesPayment-Processing
Type-DefinitionsForm-ValidierungSecurity-Rules
Test-BoilerplateError-HandlingDatenlöschung
CSS/TailwindDateioperationenVerschlüsselung
README-EntwürfeE-Mail-TemplatesZugriffskontrolle

Das Muster ist einfach: KI kümmert sich um Struktur, Menschen um Vertrauensgrenzen.

Das Fazit

Wir lieben KI-unterstützte Entwicklung. Sie macht uns messbar schneller. Aber „Vibe Coding" — KI-Code shippen ohne ihn zu lesen — ist Fahrlässigkeit, keine Innovation.

Der Kater ist real. Wir haben SQL Injections, Auth-Bypasses und Datenlecks in KI-generiertem Code gefunden, der oberflächliches Review bestanden hatte. Jedes Mal sah der Code sauber aus. Er war typisiert. Er hatte gute Variablennamen. Er war nur leider ausnutzbar.

Lest den Code. Reviewt den Code. Besonders wenn eine Maschine ihn geschrieben hat.

Quellen

Ähnliche Beiträge