Next.js Penetrationstest: Middleware-Bypass, Server Actions und ISR-Sicherheit

Next.js ist das meistgenutzte React-Full-Stack-Framework und Grundlage zahlreicher produktionskritischer Webanwendungen. Mit der Einführung des App Routers, Server Components und Server Actions entstanden neue Angriffsflächen, die sich fundamental von klassischen SPA-Sicherheitsmodellen unterscheiden. CVE-2024-43481 (CVSS 9.1) demonstrierte, dass ein einziger Middleware-Fehler die gesamte Zugriffskontrolle einer Next.js-Anwendung umgehen kann. Matproof prüft Ihre Next.js-Applikation auf alle bekannten und emergenten Schwachstellen dieser Architektur.

Next.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 Next.js-Anwendungen spezialisierte Sicherheitstests benötigen

Next.js vereint Client-Rendering, Server-Side Rendering (SSR), Static Site Generation (SSG) und Incremental Static Regeneration (ISR) in einem Framework — jede Rendering-Strategie bringt eigene Sicherheitsimplikationen mit. Server Components und Server Actions, eingeführt mit Next.js 13 und dem App Router, verschieben Logik auf den Server, ohne dass Entwickler immer die sicherheitsrelevanten Konsequenzen vollständig durchdenken. Middleware läuft in der Edge Runtime und kontrolliert Routing und Auth-Checks für die gesamte Anwendung — ein Fehler dort kompromittiert sämtliche nachgelagerte Routen. Das Next.js-Sicherheitsmodell ist komplex, gut dokumentiert, aber in der Praxis häufig fehlerhaft implementiert. CVE-2024-43481, CVE-2024-46982 und CVE-2024-34351 belegen, dass selbst aktuelle Next.js-Versionen kritische Schwachstellen enthielten, die Angreifern vollständige Autorisierungsumgehung oder Server-seitige Anfragenfälschung ermöglichten.

CVE-2024-43481 (CVSS 9.1, Next.js Middleware-Bypass): In Next.js-Versionen vor 14.2.25 und 15.x vor 15.2.3 konnte ein Angreifer durch Manipulation des x-middleware-subrequest-Headers die gesamte Middleware-Verarbeitungskette überspringen, sodass Authentifizierungs- und Autorisierungsprüfungen vollständig umgangen wurden. Diese Schwachstelle betrifft alle Anwendungen, die Middleware zur Zugriffskontrolle nutzen — eine der häufigsten Muster in Next.js-Produktivsystemen.
CVE-2024-46982 (Cache-Poisoning in Next.js ISR): Durch manipulierte HTTP-Header konnte ein Angreifer gecachte ISR-Seiten mit bösartigem Inhalt vergiften, der anschließend an alle Benutzer ausgeliefert wurde. Betroffen waren Next.js-Versionen vor 14.2.10 im Pages Router. Cache-Poisoning-Angriffe auf ISR sind besonders tückisch, da der vergiftete Cache lange bestehen bleibt.
CVE-2024-34351 (SSRF via Host-Header in Server Actions): Next.js-Versionen 13.4 bis 14.x leiteten Server-Action-Anfragen basierend auf dem Host-Header weiter, ohne diesen ausreichend zu validieren. Angreifer konnten so interne Dienste über den Next.js-Server ansprechen (Server-Side Request Forgery), was in Cloud-Umgebungen den Zugriff auf Metadaten-Endpunkte (AWS IMDSv1, Azure IMDS) ermöglichte.
Server Actions als neuer Angriffsvektor: Server Actions in Next.js 13+ sind serverseitige Funktionen, die direkt aus Client-Komponenten aufgerufen werden. Ohne explizite Autorisierungsprüfungen in jeder Action sind sie von beliebigen, nicht authentifizierten Anfragen erreichbar — ein häufiger Implementierungsfehler, der zu Privilege Escalation oder Datenlecks führt.
React Server Components und Datenlecks: RSC-Serialisierung überträgt Serverstate an den Client. Werden sensible Daten (Datenbankresultate, API-Schlüssel, interne Konfiguration) nicht explizit gefiltert, gelangen sie in die Client-Bundle oder in Netzwerk-Responses — oft unsichtbar in der normalen Anwendungsansicht, aber im Netzwerkverkehr sichtbar.
Fehlkonfigurierte Next.js-Rewrites und Redirects als Open-Redirect-Quelle: Rewrites in next.config.js können bei unsachgemässer Konfiguration Open Redirects oder SSRF-Angriffspfade öffnen, wenn externe URLs als Rewrite-Ziele konfiguriert werden.
Supply-Chain-Risiken im Next.js-Ökosystem: Next.js-Projekte nutzen typischerweise Dutzende npm-Abhängigkeiten; bekannte Supply-Chain-Angriffe (z.B. event-stream 2018, ua-parser-js 2021) demonstrieren das Risiko kompromittierter Transitivabhängigkeiten in der Produktionsumgebung.

Was beim Next.js Penetrationstest geprüft wird

Middleware-Sicherheit und Autorisierungslogik: Vollständige Analyse der middleware.ts-Konfiguration auf Header-Manipulation, Bypass-Muster (vgl. CVE-2024-43481), inkorrekte Matcher-Konfiguration und Race Conditions in Edge-Runtime-Ausführung.
Server Actions Autorisierung und Input-Validierung: Jede exportierte Server Action wird auf fehlende Authentifizierungsprüfungen, CSRF-Schutz (Next.js-eigener Origin-Check vs. custom Implementierungen), übermässige Datenbankzugriffe und Injection-Anfälligkeit untersucht.
ISR-Cache-Poisoning und Cache-Keying: Test auf Möglichkeit, gecachte Seiten durch manipulierte Anfragen zu vergiften; Analyse der Cache-Key-Konfiguration auf Variationen durch Header, Cookies oder Query-Parameter.
SSRF via Host-Header und Redirect-Logik: Systematische Tests ob Server-seitige Weiterleitungen, API-Proxies oder Rewrite-Regeln durch manipulierte Host-Header oder Pfadparameter auf interne Infrastruktur zeigen (vgl. CVE-2024-34351).
React Server Components Datenleck-Analyse: Prüfung der RSC-Payload auf enthaltene sensible Daten, interne IDs, nicht gefiltertes Datenbankresultate oder Konfigurationswerte; Analyse der __NEXT_DATA__-Payload auf exponierte Secrets.
API-Route-Sicherheit nach OWASP API Top 10 (2023): Authentifizierung, Rate-Limiting, Input-Validierung, Mass-Assignment in allen route.ts-Handlers; Test auf BOLA (Broken Object Level Authorization) bei ressourcenspezifischen Endpunkten.
Next.js-Konfiguration und Sicherheits-Header: Audit der next.config.js auf unsichere Header-Konfigurationen, fehlende Content Security Policy, deaktivierte X-Powered-By-Suppression, unsichere CORS-Konfiguration.
Dependency-Audit und Supply-Chain-Analyse: Scan aller npm-Abhängigkeiten (inkl. transitive) gegen NVD/OSV-Datenbank; Identifikation kritischer Pakete mit bekannten CVEs in der verwendeten Version.
Authentifizierungsintegration (NextAuth.js / Auth.js): Konfigurationsaudit für OAuth-Callbacks, JWT-Geheimnisse, Session-Management, CSRF-Token-Validierung und sichere Cookie-Flags.
Edge Runtime vs. Node.js Runtime Sicherheitsunterschiede: Analyse ob sicherheitskritische Logik korrekt in die jeweilige Runtime-Umgebung platziert ist und ob Edge-Runtime-Einschränkungen zu Security-Downgrades führen.

Beispiel-Befund

Kritisch

Middleware-Bypass via x-middleware-subrequest-Header (CVE-2024-43481)

Die produktive Next.js-Anwendung (Version 14.1.4) nutzt Middleware zur Authentifizierungsprüfung fuer alle geschuetzten Routen unter /app/*. Durch Hinzufuegen des Headers x-middleware-subrequest: middleware mit einem beliebigen Wert werden saemtliche Middleware-Ausfuehrungen fuer diese Anfrage uebersprungen. Im Test war es moeglich, /app/dashboard, /app/admin und /app/api/internal-data ohne gueltigen Authentifizierungs-Cookie zu erreichen und sensitive Nutzer- sowie Konfigurationsdaten abzurufen. Die Schwachstelle (CVE-2024-43481, CVSS 9.1) ist in Next.js-Versionen vor 14.2.25 und 15.x vor 15.2.3 vorhanden.

Behebung: Sofortiges Update auf Next.js 14.2.25 (LTS) oder 15.2.3+. Als Defense-in-Depth: Autorisierungspruefungen zusaetzlich in jedem Server Component und jeder Server Action implementieren, nie ausschliesslich auf Middleware-Ebene vertrauen. Den x-middleware-subrequest-Header in der eigenen Infrastruktur (Reverse Proxy / CDN) blockieren, wenn er von externen Quellen kommt. Verweis: Next.js Security Advisory GHSA-f82v-jwr5-mffw.

Referenz: CVE-2024-43481 (CVSS 9.1) · GHSA-f82v-jwr5-mffw · OWASP A01:2021 Broken Access Control · NVD next.js

Next.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

Next.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 Next.js Penetrationstest

Welche Next.js-Versionen sind von CVE-2024-43481 betroffen und wie erkenne ich ob meine Anwendung vulnerabel ist?

CVE-2024-43481 betrifft Next.js-Versionen von 11.1.4 bis vor 14.2.25 sowie 15.x vor 15.2.3. Sie koennen Ihre Version mit 'npx next --version' pruefen. Eine schnelle manuelle Pruefung: Senden Sie eine Anfrage an eine geschuetzte Route mit dem zusaetzlichen Header 'x-middleware-subrequest: middleware' und beobachten Sie, ob die Middleware-Pruefung uebersprungen wird. Empfohlen wird das sofortige Update auf die aktuelle Patch-Version. Matproof Sentinel prueft dies automatisiert bei jedem Scan.

Muessen Server Actions in Next.js explizit abgesichert werden oder genuegt die Middleware-Authentifizierung?

Server Actions muessen immer explizit abgesichert werden. Die Next.js-Dokumentation stellt klar, dass Server Actions als oeffentlich erreichbare API-Endpunkte zu behandeln sind. Middleware-Authentifizierung schuetzt nur das Routing, nicht den Action-Aufruf selbst. Best Practice: In jeder Server Action auth() oder eine equivalente Session-Pruefung als erste Anweisung einfuegen, bevor irgendeine Datenbankoperation ausgefuehrt wird. Bibliotheken wie next-safe-action unterstuetzen strukturiertes Autorisierungs-Middleware fuer Server Actions.

Wie funktioniert ISR-Cache-Poisoning in Next.js und welche Seiten sind besonders gefaehrdet?

ISR (Incremental Static Regeneration) generiert statische Seiten server-seitig und cached sie. CVE-2024-46982 zeigte, dass durch manipulierte Header (z.B. Accept-Encoding oder X-Forwarded-For) unterschiedliche Cache-Keys erzeugt werden konnten, sodass ein Angreifer eine vergiftete Version einer Seite in den Cache einspeisen konnte. Besonders gefaehrdet sind oeffentlich zugaengliche ISR-Seiten mit personalisierten Elementen oder sicherheitsrelevanten Inhalten. Update auf Next.js 14.2.10+ behebt die gemeldete Schwachstelle.

Wie sollte man SSRF in Next.js-Server-Actions und API-Routes verhindern?

SSRF-Praevention in Next.js erfordert: (1) Validierung des Host-Headers im Reverse Proxy und Ablehnung unbekannter Hosts; (2) Whitelisting erlaubter externer URLs bei Weiterleitungen und Fetch-Calls aus Server-Kontext; (3) Blockieren von Anfragen an IANA-reservierte Adressbereiche (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16 fuer Cloud-Metadaten); (4) Verwendung von next.config.js 'images.remotePatterns' und aehnlichen Allowlists fuer externe Ressourcen. CVE-2024-34351 demonstrierte, wie Host-Header-Manipulation in Server Actions zu SSRF fuehren kann.

Welche Content Security Policy (CSP) Konfiguration wird fuer Next.js-Anwendungen empfohlen?

Fuer Next.js 13+ mit App Router empfiehlt sich eine nonce-basierte CSP, die mit next.config.js-Headers oder Middleware konfiguriert wird. Minimale CSP: default-src 'self'; script-src 'self' 'nonce-{nonce}'; style-src 'self' 'nonce-{nonce}'; img-src 'self' data: https:; connect-src 'self'; frame-ancestors 'none'. Der Next.js-eigene Inline-Script fuer RSC-Hydration muss via Nonce erreichbar sein. 'unsafe-inline' und 'unsafe-eval' sollten vermieden werden. Matproof prueft die CSP-Konfiguration auf gaugige Bypass-Moeglichkeiten.

Wie sicher ist NextAuth.js (Auth.js) und was wird beim Pentest geprueft?

NextAuth.js (jetzt Auth.js) ist eine weit verbreitete Authentifizierungs-Bibliothek fuer Next.js. Beim Pentest pruefen wir: korrekte Konfiguration des AUTH_SECRET (min. 32 Bytes, nicht in .env.production committed), CSRF-Token-Validierung fuer alle POST-Endpoints, sichere Konfiguration von OAuth-Providern (Redirect-URI-Validierung, State-Parameter), JWT-Algorithmus und Schluessel-Rotation, Session-Cookie-Flags (HttpOnly, Secure, SameSite=Lax), sowie Middleware-Integration fuer Route-Schutz.

Was unterscheidet einen spezialisierten Next.js Pentest von einem generischen Web-App-Pentest?

Ein generischer Web-App-Pentest folgt dem OWASP Testing Guide und deckt allgemeine Schwachstellenklassen ab. Ein spezialisierter Next.js Pentest adressiert zusaetzlich framework-spezifische Angriffsflaechen: App-Router-Routing-Logik, Server-vs-Client-Component-Datenboundaries, Server-Action-Endpunkt-Enumeration, ISR-Revalidierungs-Mechanismen, Edge-Runtime-Einschraenkungen, __NEXT_DATA__-Payload-Analyse und den Next.js-eigenen Request-Lifecycle. Diese Ebene erfordert detailliertes Framework-Wissen, das generische Tools nicht abdecken.

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

Empfehlung: Vollstaendiger Pentest bei jedem Major-Release (z.B. Migration von Pages Router auf App Router, Next.js-Version-Upgrade), sowie mindestens jaehrlich fuer Produktionsanwendungen mit sensiblen Daten. Fuer kontinuierliche Sicherheit ergaenzt Matproof Sentinel den jaehrlichen Pentest durch automatisierte Scans nach jedem Deployment, die neue CVEs und Konfigurationsdrifts erkennen.

Vertiefen — verwandte Artikel aus unserem Blog

Next.js Penetrationstest jetzt starten

Ermitteln Sie in wenigen Minuten, ob Ihre Next.js-Anwendung durch Middleware-Bypass, Server-Action-Schwachstellen oder ISR-Cache-Poisoning gefaehrdet ist. Audit-bereiter Bericht auf Deutsch, keine Installation erforderlich.