Cursor & Code von KI: Warum die Object-Merge-Funktion gefährlich ist

Ein befreundeter Entwickler bat mich letzte Woche, seinen Node.js-Backend-Code zu prüfen. Das Projekt war in Cursor entstanden, mit klarer Struktur, sinnvollen Variablennamen und sogar einigen Kommentaren. Doch bei den Utility-Funktionen stach etwas hervor – eine vermeintlich banale Deep-Merge-Funktion. Etwas, das KI-Tools wie Cursor oder Claude Code in Sekunden generieren. Doch diese Funktion enthält ein gefährliches Sicherheitsrisiko, das jeder Entwickler kennen sollte.

Die unsichtbare Gefahr: Prototype Pollution durch Object Merge

Die von Cursor automatisch generierte Funktion sah zunächst harmlos aus. Sie sollte zwei Objekte tiefgehend zusammenführen – eine Standardaufgabe in vielen Backends. Doch der Teufel steckt im Detail: Die Implementierung nutzt for...in, um durch die Schlüssel des source-Objekts zu iterieren. Das Problem? for...in durchläuft nicht nur die eigenen Eigenschaften eines Objekts, sondern auch vererbte – inklusive __proto__, einer speziellen Eigenschaft, die das Prototypenvererbungsmodell von JavaScript steuert.

Angenommen, ein Angreifer kontrolliert das source-Objekt – sei es über eine manipulierte JSON-Payload, einen Query-Parameter oder eine manipulierte Konfigurationsdatei. Dann könnte er __proto__ als Schlüssel einbauen und damit das gesamte Object.prototype des Node.js-Prozesses verändern. Ein einfaches Beispiel:

deepMerge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));
console.log({}.isAdmin); // true — jedes Objekt im Prozess hat nun isAdmin: true

Die Konsequenzen sind verheerend: Authentifizierungsprüfungen wie req.user.isAdmin werden umgangen, Admin-Endpunkte werden öffentlich zugänglich, und Audit-Logs könnten manipuliert werden. Plötzlich ist die gesamte Anwendung kompromittiert – und das nur, weil eine KI-generierte Utility-Funktion eine uralte JavaScript-Schwachstelle reproduziert hat.

Warum KI-Tools diese unsichere Methode bevorzugen

Die Antwort liegt in der Trainingsdatenbasis, auf der große Sprachmodelle wie Cursor oder Copilot basieren. Zwischen 2013 und 2019 war die for...in-Methode zur Object-Merge-Implementierung der de-facto-Standard auf StackOverflow und in unzähligen Blogartikeln. Tausende upvoted Antworten, hunderte npm-Pakete und dutzende Tutorials verbreiteten diesen Ansatz – ohne je auf die Sicherheitsrisiken hinzuweisen.

Erst in den letzten Jahren haben sich sicherere Alternativen wie Object.hasOwn() oder die explizite Prüfung von __proto__ durchgesetzt. Diese Methoden sind zwar in den Trainingsdaten vorhanden, aber hauptsächlich in spezialisierten Sicherheitsartikeln – nicht in den generischen "Wie merge ich Objekte in JavaScript?"-Posts, die den Großteil des Korpus ausmachen. Für ein Sprachmodell ist die for...in-Methode schlicht die statistisch wahrscheinlichste Antwort, es sei denn, der Kontext deutet explizit auf Sicherheit hin.

So beheben Sie das Problem – in zwei einfachen Schritten

Die gute Nachricht: Die Behebung ist denkbar einfach. Es gibt zwei bewährte Ansätze, je nach Bedarf.

Methode 1: Schutz mit `Object.hasOwn()` (minimaler Aufwand)

function deepMerge(target, source) {
  for (const key in source) {
    if (!Object.hasOwn(source, key)) continue; // Blockiert __proto__ und vererbte Schlüssel
    if (source[key] && typeof source[key] === 'object') {
      target[key] = deepMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

Diese Methode behält die bestehende Logik bei, fügt aber eine einfache Prüfung hinzu, die verhindert, dass vererbte Eigenschaften – einschließlich __proto__ – übernommen werden.

Methode 2: Wechsel zu `Object.keys()` (komplette Lösung)

function deepMerge(target, source) {
  Object.keys(source).forEach(key => {
    if (source[key] && typeof source[key] === 'object') {
      target[key] = deepMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  });
  return target;
}

Hier wird Object.keys() verwendet, das nur die eigenen, enumerierbaren Eigenschaften eines Objekts zurückgibt. Vererbte Eigenschaften wie __proto__ werden automatisch ausgeschlossen. Der Code wird zudem etwas sauberer und vermeidet potenzielle Edge Cases.

Falls Sie unvertrauenswürdige JSON-Daten verarbeiten, können Sie zusätzlich eine Formvalidierung einbauen:

function isSafeObject(obj) {
  return !('__proto__' in obj) && 
         !('constructor' in obj) && 
         !('prototype' in obj);
}

Diese Funktion prüft, ob das Objekt gefährliche Schlüssel enthält, und lehnt manipulierte Payloads ab, bevor sie die Merge-Funktion erreichen.

Prototype Pollution ist überall – ein oft übersehener Risikofaktor

Doch Vorsicht: Diese unsichere Merge-Logik taucht nicht nur in Utility-Funktionen auf. Häufig findet man sie in:

• - Konfigurationsladern, die Benutzereinstellungen mit Standardwerten zusammenführen
• - Patch-Endpunkten, die Client-Daten mit Server-Daten kombinieren
• - Settings-Managern, die Umgebungsvariablen mit Defaults überschreiben

Ein einfacher Tipp: Durchsuchen Sie Ihren Code nach dem Muster for (const key in und prüfen Sie jede Fundstelle kritisch. Die Angriffsfläche ist oft größer als zunächst angenommen. Selbst wenn nur eine einzige Datei betroffen ist, kann die gesamte Anwendung gefährdet sein.

Ich nutze für die automatische Erkennung solcher Muster SafeWeave, eine Lösung, die als MCP-Server in Cursor und Claude Code integriert ist und gefährliche Code-Muster in Echtzeit markiert. Doch selbst ein einfacher Pre-Commit-Hook mit Tools wie Semgrep oder Gitleaks kann viele dieser Probleme frühzeitig erkennen. Der Schlüssel liegt darin, die Schwachstelle frühzeitig zu erkennen – egal mit welchem Tool.

Die nächste Generation von KI-Entwicklungstools wird hoffentlich sicherere Code-Vorschläge liefern. Doch bis dahin liegt die Verantwortung beim Entwickler: Prüfen Sie den von KI generierten Code kritisch, insbesondere bei sicherheitsrelevanten Funktionen. Eine einfache Zeile kann den Unterschied zwischen einem sicheren und einem kompromittierten System ausmachen.