Node.js und Express Penetrationstest: Prototype Pollution, Supply-Chain-Sicherheit und SSRF-Praevention

Node.js und das Express-Framework sind die Grundlage eines grossen Teils der modernen Web-Backend-Infrastruktur -- von RESTful APIs und Microservices bis hin zu Echtzeit-Anwendungen mit WebSockets. Das JavaScript-Oekosystem bietet unvergleichliche Entwicklungsgeschwindigkeit, bringt aber einzigartige Sicherheitsrisiken mit sich: Prototype Pollution ist eine JavaScript-spezifische Angriffstechnik, die in schwerwiegendsten Faellen zu Remote-Code-Execution eskaliert. CVE-2024-39338 demonstrierte SSRF in der weitverbreiteten axios-Bibliothek. Das npm-Oekosystem mit ueber 2,5 Millionen Paketen ist gleichzeitig das groesste Supply-Chain-Angriffsziel der Softwarewelt.

Node.js Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

Warum Node.js-Anwendungen spezialisierte Sicherheitspruefungen benoetigen

Node.js-Sicherheit unterscheidet sich fundamental von traditionellen Server-Sprachen. Prototype Pollution ist eine JavaScript-spezifische Schwachstelle, bei der ein Angreifer die Prototyp-Kette von JavaScript-Objekten manipuliert und so Eigenschaften in alle Objekte der Anwendung einfuegt. In Kombination mit bestimmten Code-Patterns fuehrt dies zu Denial-of-Service, Security-Bypass oder Remote-Code-Execution. Das npm-Oekosystem ist anfaellig fuer Supply-Chain-Angriffe: Typosquatting, Dependency-Confusion und kompromittierte Pakete. CVE-2023-44487 (HTTP/2 Rapid Reset) betraf Node.js-Server direkt und ermoeglichte effektive DDoS-Angriffe. CVE-2022-23529 in jsonwebtoken demonstrierte, wie eine kritische Auth-Bibliothek zur RCE-Quelle werden kann.

CVE-2024-39338 (axios SSRF): axios, mit ueber 100 Millionen wochentlichen Downloads eines der meistgenutzten HTTP-Client-Pakete, enthielt eine SSRF-Schwachstelle (Server-Side Request Forgery), die es Angreifern ermoeglichte, interne Dienste ueber den Node.js-Server anzusprechen. Betrifft axios vor 1.7.4. In Cloud-Umgebungen koennen SSRF-Angriffe auf AWS-IMDSv1 zu vollstaendiger Credential-Kompromittierung fuehren.
CVE-2023-44487 (HTTP/2 Rapid Reset, CVSS 7.5): Diese Schwachstelle betrifft alle Server-Implementierungen, die HTTP/2 unterstuetzen, einschliesslich Node.js. Durch schnelles Oeffnen und Abbrechen von HTTP/2-Streams koennen Angreifer einen effizienten DDoS-Angriff durchfuehren. Node.js-Versionen vor 18.19.0 und 20.x vor 20.11.0 sind betroffen.
CVE-2022-23529 (jsonwebtoken Remote-Code-Execution): jsonwebtoken, die haeufigste JWT-Bibliothek fuer Node.js, enthielt eine kritische Schwachstelle, bei der ein manipuliertes JWT-Secret zu Remote-Code-Execution fuehren konnte. Betrifft jsonwebtoken vor 9.0.0. Viele Anwendungen verwenden noch veraltete Versionen dieser Bibliothek.
Prototype Pollution in Node.js: Durch Manipulation von '__proto__', 'constructor.prototype' oder 'prototype' in JSON-Objekten kann ein Angreifer Eigenschaften in den globalen Object-Prototyp einschleusen. Dies betrifft alle abgeleiteten Objekte und kann zu Authentication-Bypass (if (req.isAdmin)) oder RCE fuehren, wenn Merge-Funktionen wie lodash.merge, lodash.set oder _.defaultsDeep betroffen sind.
Supply-Chain-Angriffe im npm-Oekosystem: Bekannte Angriffsvektoren: Typosquatting (confusingly named packages), kompromittierte Maintainer-Accounts, Dependency-Confusion-Angriffe (private Paket wird durch oeffentliches ersetzt), und postinstall-Skripte in Abhaengigkeiten. Jedes 'npm install' fuehrt potenziell unbekannten Code aus.
Unsichere Deserialisierung von JSON und anderen Formaten: Node.js-Anwendungen, die serialize-javascript, node-serialize oder aehnliche Bibliotheken verwenden, sind anfaellig fuer Deserialisierungs-Angriffe. Auch YAML-Parsing (js-yaml safeLoad vs. load) und eval-basierte Muster eroeffnen Code-Execution-Pfade.
Fehlkonfigurierte Express-Middleware-Reihenfolge als Sicherheitsluecke: In Express bestimmt die Reihenfolge der Middleware, welche Sicherheitspruefungen auf welche Routen angewendet werden. Authentifizierungs-Middleware nach Route-Definitionen, rate-limiting vor statt nach statischen Dateien und Logging-Middleware die Secrets erfasst -- all diese Fehler entstehen durch Middleware-Reihenfolge.

Was beim Node.js / Express Penetrationstest geprueft wird

Prototype-Pollution-Analyse: Systematisches Testen aller Endpunkte, die JSON-Eingaben mit rekursiven Merge-Operationen verarbeiten; Test ob '__proto__', 'constructor' oder 'prototype'-Schluessel in Request-Bodies akzeptiert werden; Eskalationstest auf Authentication-Bypass oder RCE.
npm-Dependency-Audit und Supply-Chain-Risiken: Scan von package.json und package-lock.json gegen npm audit, Snyk und NVD; Identifikation kritischer CVEs in Transitivabhaengigkeiten; Pruefung auf bekannte Typosquatting-Pakete; postinstall-Skript-Analyse.
SSRF-Tests (CVE-2024-39338 und aequivalente): Pruefung ob HTTP-Client-Aufrufe (axios, node-fetch, got) mit Benutzer-kontrollierten URLs ausgefuehrt werden; Test auf Zugriff zu internen Diensten und Cloud-Metadaten-Endpunkten (169.254.169.254); Redirect-Following-Verhalten.
JWT-Sicherheit (jsonwebtoken/jose): JWT-Algorithm-Confusion; 'none'-Algorithmus; schwache Secrets; Token-Expiration; Refresh-Token-Sicherheit; CVE-2022-23529-Abdeckung; Pruefung ob aktuelle jsonwebtoken-Version verwendet wird.
Express-Middleware-Sicherheitsanalyse: Pruefung der Middleware-Reihenfolge; helmet.js-Konfiguration (Security-Header); cors-Konfiguration (Origin-Whitelist vs. Wildcard); express-rate-limit; Body-Parser-Groesseneinschraenkungen.
HTTP/2 und Server-Haertung (CVE-2023-44487): Pruefung ob HTTP/2 aktiviert ist und welche Node.js-Version verwendet wird; Test auf Rapid-Reset-Anfaelligkeit; Empfehlungen zu Limits (maxHeaderListPairs, maxSessionMemory).
Unsichere Deserialisierung und eval-Verwendung: Code-Analyse auf eval(), Function(), vm.runInNewContext() mit Benutzerinput; YAML-Parsing ohne SafeLoad; serialize-javascript und node-serialize Verwendung.
WebSocket-Sicherheit (falls vorhanden): Authentifizierung bei WebSocket-Verbindungen; Message-Validierung; DoS durch grosse Messages; Cross-Site-WebSocket-Hijacking.
Umgebungsvariablen und Secret-Management: Pruefung ob Secrets korrekt aus process.env gelesen werden und nicht hardkodiert sind; .env-Datei-Exposition; Logging-Konfiguration auf unbeabsichtigte Secret-Ausgabe.
GraphQL-Sicherheit (falls Apollo/Nexus verwendet): Introspection in Produktion; Query-Complexity-Limits; Batching-Angriffe; Authorization-Granularitaet; N+1-Query-Erkennung als potenzielle DoS-Vektoren.

Beispiel-Befund

Hoch

Prototype Pollution via JSON-Merge-Funktion ermoeglicht Authentication-Bypass

Die API-Endpunkt PUT /api/v1/user/settings verwendet eine benutzerdefinierte Deep-Merge-Funktion (merge(target, source)) ohne Schutz gegen Prototype-Pollution. Durch Senden von {'__proto__': {'isAdmin': true}} im Request-Body konnte der globale Object-Prototyp manipuliert werden, sodass alle nachfolgenden Objekte im Prozess 'isAdmin: true' als Eigenschaft haben. Da die Admin-Pruefung 'if (req.user.isAdmin)' auf genau diese Eigenschaft prueft, waren alle Admin-Endpunkte nach der Manipulation zugaenglich -- bis zum Server-Neustart.

Behebung: Tiefe Merge-Operationen durch sichere Implementierungen ersetzen: lodash.merge auf Version >= 4.17.21 aktualisieren (enthaelt Prototype-Pollution-Schutz); Object.assign() statt rekursivem Merge fuer flache Objekte; JSON-Schema-Validierung die '__proto__', 'constructor' und 'prototype'-Schluessel explizit ablehnt. Alternative: strukturierten Clone (structuredClone()) oder JSON.parse(JSON.stringify(obj)) fuer sichere Tiefenkopie.

Referenz: CVE-2024-39338 (axios SSRF) · CVE-2022-23529 (jsonwebtoken RCE) · OWASP A08:2021 Software and Data Integrity Failures · CWE-1321 Improperly Controlled Modification of Object Prototype Attributes

Node.js Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

Node.js Pentest Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Haeufige Fragen zum Node.js Penetrationstest

Was ist Prototype Pollution in Node.js und wie gefaehrlich ist diese Schwachstelle?

Prototype Pollution ist eine JavaScript-spezifische Schwachstelle, bei der ein Angreifer '__proto__' oder 'constructor.prototype' in Objekten manipuliert, um Eigenschaften in den globalen Prototyp einzuschleusen. Da alle JavaScript-Objekte von diesem Prototyp erben, betrifft die Manipulation alle nachfolgenden Objekte im Prozess. In milden Faellen fuehrt dies zu Denial-of-Service oder unerwarteten Anwendungsfehlern. In schweren Faellen -- wenn bestimmte Ausfuehrungs-Pfade betroffen sind -- kann Prototype Pollution zu Authentication-Bypass oder Remote-Code-Execution eskalieren (z.B. via child_process.exec mit vergifteten Optionen).

Wie sichert man axios-basierte HTTP-Anfragen in Node.js gegen SSRF ab?

Nach CVE-2024-39338: Sofortiges Update auf axios >= 1.7.4. Generelle SSRF-Praevention: (1) Niemals Benutzer-kontrollierte URLs direkt an axios uebergeben; (2) URL-Whitelist implementieren fuer erlaubte externe Hosts; (3) axios-Interceptor fuer URL-Validierung vor jedem Request; (4) Deaktivierung von Redirect-Following oder Limit auf max. 2 Redirects; (5) Blockierung von Anfragen an private IP-Ranges (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16) via Netzwerk-Policy oder Middleware.

Wie reduziere ich Supply-Chain-Risiken in meinem Node.js-Projekt?

Mehrschichtige Supply-Chain-Sicherheit: (1) package-lock.json und npm ci statt npm install in CI/CD; (2) npm audit und Snyk in die CI-Pipeline integrieren; (3) Abhaengigkeiten regelmaessig mit 'npm outdated' pruefen; (4) Minimale Abhaengigkeiten -- jedes Package ist ein Risiko; (5) Vertrauen in Pakete mit hoher Download-Zahl und aktiver Wartung; (6) postinstall-Skripte in node_modules auditieren; (7) Signaturen via npm provenance pruefen (NPM Provenance, seit 2023 verfuegbar).

Welche Sicherheits-Header sollte jede Express-Anwendung setzen?

Mindestkonfiguration mit Helmet.js: app.use(helmet()); -- aktiviert standardmaessig: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, X-XSS-Protection: 0 (modern), Strict-Transport-Security, Referrer-Policy. Zusaetzlich empfohlen: Content-Security-Policy (erfordert anwendungsspezifische Konfiguration), Permissions-Policy, Cross-Origin-Embedder-Policy und Cross-Origin-Opener-Policy fuer moderne Sicherheitsanforderungen. CORS korrekt konfigurieren: Niemals 'origin: *' in Produktion fuer credentialled Requests.

Wie erkenne ich ob meine Node.js-Anwendung durch CVE-2023-44487 (HTTP/2 Rapid Reset) gefaehrdet ist?

CVE-2023-44487 betrifft alle Node.js-Versionen vor 18.19.0 und 20.x vor 20.11.0, die HTTP/2 unterstuetzen. Pruefung: 'node --version' und Vergleich mit Patch-Versionen. In Express-Anwendungen, die hinter einem Reverse Proxy (nginx, Cloudflare, AWS ALB) betrieben werden, wird HTTP/2 oft vom Proxy terminiert -- in diesem Fall ist die Node.js-Anwendung selbst moeglicherweise nicht direkt exponiert, aber der Proxy muss ebenfalls gepatcht sein.

Wie sichert man JWT-Authentifizierung in Express korrekt ab?

Sichere JWT-Implementierung in Express: (1) Aktuelle jsonwebtoken-Version (>= 9.0.0) nach CVE-2022-23529; (2) Explizite Algorithmus-Einschraenkung: jwt.verify(token, secret, { algorithms: ['RS256'] }); (3) Starke Secrets (min. 256 Bit fuer HS256, RSA-2048+ fuer RS256); (4) Kurze Access-Token-Lebensdauer (15-60 Min.); (5) Refresh-Token-Rotation mit Revocation-Unterstuetzung; (6) Token in httpOnly-Cookies statt localStorage fuer Browser-Clients; (7) Nie den Algorithmus aus dem Token-Header lesen ohne Validierung.

Was sind die haeufigsten Sicherheitsfehler in GraphQL-APIs mit Apollo Server?

Haeufige GraphQL-Sicherheitsfehler: (1) Introspection in Produktion aktiv -- exponiert das gesamte Schema und erleichtert Angriffe; (2) Kein Query-Depth-Limit oder Query-Complexity-Limit -- ermoeglicht DoS durch tief verschachtelte Queries; (3) Kein Batching-Limit -- ermoeglicht Brute-Force via Alias-Batching; (4) Authorization auf Resolver-Ebene vergessen (nur auf Schema-Ebene); (5) N+1-Queries als DoS-Vektor ohne DataLoader.

Wie oft sollte eine Node.js-Anwendung einem Penetrationstest unterzogen werden?

Empfehlung: Vollstaendiger Pentest bei Major-Versionsaenderungen (z.B. Node.js 18 auf 20), nach Architektureaenderungen und mindestens einmal jaehrlich. Da das npm-Oekosystem besonders schnell neue CVEs produziert, ist kontinuierliches Monitoring (Matproof Sentinel, Snyk) zwischen den Jahrespentests besonders wertvoll. Kritische npm-CVEs werden regelmaessig innerhalb von Stunden nach Veroeffentlichung aktiv ausgenutzt.

Vertiefen — verwandte Artikel aus unserem Blog

Node.js Penetrationstest jetzt starten

Schutzen Sie Ihre Node.js-Anwendung vor Prototype-Pollution, Supply-Chain-Angriffen und SSRF. Audit-bereiter Bericht auf Deutsch, keine Installation erforderlich.