Sicherheitslücken in KI-generiertem Code: Die 6 häufigsten Fehler

KI-Werkzeuge schreiben heute Code, der funktioniert. Ob er auch sicher ist, ist eine andere Frage. Veracode hat für eine große Studie Code von über 100 Sprachmodellen geprüft: In 45 Prozent der Fälle enthielt er Lücken aus den OWASP Top 10, also den häufigsten Schwachstellen im Web (Veracode, 2025). Bemerkenswert: Neuere und größere Modelle schnitten dabei nicht besser ab als ältere.

Das Problem ist nicht, dass KI schlechten Code schreibt. Das Problem ist, dass sie tut, was man ihr sagt, und selten, was man vergessen hat zu sagen. Hier sind sechs Lücken, die in KI-generierten Projekten besonders häufig vorkommen, jeweils mit Beispiel und Lösung.

Kurz gesagt

• Laut Veracode enthielt KI-generierter Code in 45 Prozent der Tests bekannte Sicherheitslücken.
• Die häufigsten Fehler: Preise aus dem Browser, fehlende Zugriffsprüfung, Datenbanken ohne Row Level Security, Geheimnisse im Frontend, persönliche Daten im Log und ungeprüfte Eingaben.
• Die gröbsten Lücken findest du mit einer 30-Minuten-Prüfung selbst.

1. Der Browser bestimmt den Preis

Ein Klassiker bei Checkouts: Der Betrag kommt aus der Anfrage des Browsers, statt auf dem Server aus dem Produkt gelesen zu werden.

// Unsicher: Der Betrag kommt vom Browser
const { productId, amount } = await req.json();
await stripe.checkout.sessions.create({
  mode: "payment",
  line_items: [{
    quantity: 1,
    price_data: {
      currency: "eur",
      unit_amount: amount,
      product_data: { name: productId },
    },
  }],
});

Wer die Anfrage verändert, zahlt einen Cent. Die Lösung: Der Server holt den Preis selbst.

// Sicher: Der Preis kommt vom Server
const { productId } = await req.json();
const unitAmount = await priceFor(productId);

Die Regel dahinter gilt nicht nur für Preise: Alles, was aus dem Browser kommt, ist ein Vorschlag, keine Tatsache. Das betrifft auch Rollen, Rabatte, Mengen und Nutzer-IDs.

2. API-Routen ohne Zugriffsprüfung

Die Oberfläche zeigt einen Button nur angemeldeten Nutzern, die Route dahinter prüft aber nichts. Wer die Adresse kennt, ruft sie direkt auf.

// Unsicher: keine Prüfung, wer hier anfragt
export async function POST(req) {
  const { orderId } = await req.json();
  return Response.json(await db.order.delete(orderId));
}

Die Lösung: Jede Route prüft selbst, ob eine gültige Sitzung besteht und ob diese Person genau diesen Datensatz ändern darf.

export async function POST(req) {
  const user = await requireUser(req);
  const { orderId } = await req.json();
  const order = await db.order.find(orderId);
  if (order.ownerId !== user.id) {
    return new Response("Forbidden", { status: 403 });
  }
  return Response.json(await db.order.delete(orderId));
}

3. Die Datenbank ohne Zugriffsregeln

Viele KI-Werkzeuge bauen auf Supabase oder Firebase. Dort greift der Browser direkt auf die Datenbank zu, geschützt nur durch Zugriffsregeln. Bei Supabase heißen sie Row Level Security. Fehlen sie, kann jeder mit dem öffentlichen Schlüssel ganze Tabellen auslesen.

Genau das ist 2025 bei vielen Lovable-Apps passiert: Nutzerdaten, API-Schlüssel und Zahlungsdaten waren für Fremde lesbar (CVE-2025-48757).

Die Lösung: Row Level Security für jede Tabelle aktivieren und Regeln schreiben, die festlegen, wer welche Zeilen lesen und ändern darf. Danach in einem nicht angemeldeten Browser testen, ob wirklich nichts mehr durchkommt.

4. Geheimnisse im Frontend

API-Schlüssel für Zahlungen, KI-Dienste oder E-Mail-Versand landen in Code, der an den Browser ausgeliefert wird. Jeder kann sie im Quelltext finden und auf deine Kosten nutzen.

Typische Stellen: Umgebungsvariablen mit dem Präfix NEXT_PUBLIC_ oder VITE_, der Service-Role-Schlüssel von Supabase im Client oder Schlüssel direkt im Code.

Die Lösung: Geheime Schlüssel gehören ausschließlich auf den Server. Im Browser landet nur, was öffentlich sein darf. Und ein Schlüssel, der einmal öffentlich war, wird nicht versteckt, sondern ausgetauscht.

5. Persönliche Daten im Log

Zum Debuggen schreibt die KI gern alles ins Log: E-Mail-Adressen, Namen, manchmal ganze Anfragen.

console.log("checkout", email);

Logs wandern zu Hostern, Monitoring-Diensten und Fehlertrackern. Damit verarbeitest du personenbezogene Daten an Stellen, die niemand auf dem Schirm hat, auch nicht in der Datenschutzerklärung. Die Lösung: nur loggen, was die Fehlersuche braucht, zum Beispiel eine Bestellnummer statt der E-Mail-Adresse.

6. Ungeprüfte Eingaben

Was Nutzer eingeben, landet ungefiltert in der Datenbank oder auf der Seite. Die Folge sind Cross-Site-Scripting und Injection-Angriffe. Laut Veracode scheiterten die getesteten Modelle beim Schutz vor Cross-Site-Scripting in 86 Prozent der relevanten Fälle (Veracode, 2025).

Dazu gehört auch fehlende Begrenzung: Ein Formular ohne Rate Limit lässt sich tausendfach pro Minute abschicken, ein Login ohne Begrenzung lädt zum Durchprobieren von Passwörtern ein.

Die Lösung: Eingaben auf dem Server prüfen, bei der Ausgabe escapen, Datenbankabfragen parametrisieren und sensible Endpunkte begrenzen.

So prüfst du deine App in 30 Minuten

Du musst kein Sicherheitsexperte sein, um die gröbsten Lücken zu finden:

1. Browser-Werkzeuge öffnen: Schau dir im Netzwerk-Tab an, was deine App sendet. Tauchen Preise, Rollen oder IDs auf, die du verändern könntest?
2. Abgemeldet testen: Rufe API-Adressen in einem privaten Fenster ohne Login auf. Kommen Daten zurück?
3. Quelltext durchsuchen: Suche im ausgelieferten JavaScript nach „key“, „secret“ und „token“.
4. Datenbank-Regeln prüfen: Ist Row Level Security bei jeder Tabelle aktiv, und gibt es passende Regeln?
5. Logs ansehen: Stehen dort E-Mail-Adressen, Namen oder Zahlungsdaten?

Findest du etwas, ist das kein Grund zur Panik. Aber ein Grund, vor dem nächsten Nutzer zu handeln.

Warum Werkzeuge allein nicht reichen

Automatische Scanner finden einen Teil dieser Fehler. Viele Lücken sind aber Logikfehler: Die Route funktioniert technisch einwandfrei, sie prüft nur das Falsche. Dafür braucht es jemanden, der versteht, was die App tun soll, und gezielt fragt, was sie nicht tun darf.

So arbeite ich mit meiner AI-Crew: Vera prüft den Code auf genau diese Muster, bei Zahlungen, Datenschutz und Login. Jeden Befund bewerte ich selbst, bevor etwas behoben wird oder live geht. Maschinelle Gründlichkeit und menschliches Urteil finden zusammen mehr als jedes für sich.

Häufige Fragen

Ist KI-generierter Code unsicher?

Nicht grundsätzlich, aber häufig. In einer Studie von Veracode enthielt KI-generierter Code in 45 Prozent der Tests Lücken aus den OWASP Top 10. Größere Modelle schnitten dabei nicht besser ab.

Was ist Row Level Security?

Row Level Security sind Zugriffsregeln direkt in der Datenbank, zum Beispiel bei Supabase. Sie legen fest, welche Nutzer welche Zeilen lesen oder ändern dürfen. Ohne sie kann jeder mit dem öffentlichen Schlüssel Daten auslesen.

Wie prüfe ich meine App auf Sicherheitslücken?

Prüfe, was die App an den Server sendet, rufe Schnittstellen ohne Login auf, durchsuche den ausgelieferten Code nach Schlüsseln, kontrolliere die Datenbankregeln und sieh dir die Logs an. Für Produkte mit echten Nutzern lohnt sich zusätzlich ein Review durch eine erfahrene Person.

Fazit

KI-generierter Code ist nicht deshalb unsicher, weil KI schlecht programmiert, sondern weil Sicherheit selten im Prompt steht. Wer die sechs typischen Lücken kennt, findet die meisten davon in einer halben Stunde. Wer ein Produkt mit echten Nutzern und echtem Geld betreibt, sollte trotzdem jemanden draufschauen lassen, der weiß, wonach er sucht.