Schweregrad MittelFehlerbehandlung & Resilienz

Ausführliche Fehlerseiten und Stack Traces in Produktion

Wenn eine unbehandelte Exception oder eine Anfrage auf eine nicht existierende Route in Produktion die Debug-Fehleransicht eines Frameworks auslöst, kann das einem Angreifer eine Karte deines Servers liefern: Dateipfade, Zeilennummern, Bibliotheksversionen und manchmal Umgebungsvariablen. Die Lösung: Liefere Nutzern generische Fehlerantworten und protokolliere die vollständigen Details nur in einem serverseitigen Dienst, den dein Team kontrolliert.

Was es ist

Jedes Web-Framework bringt eine eingebaute Debug-Fehleransicht mit — Djangos gelbe Exception-Seite, Laravels Ignition-Screen, das Entwicklungs-Overlay von Next.js, der Standard-Exception-Dump von Express. Während der Entwicklung sind sie unverzichtbar, in Produktions-Builds aber bewusst deaktiviert. Das Risiko sind Framework-Fehlerseiten, die aktiv bleiben, weil der Debug-Modus nicht abgeschaltet wurde, oder eigene Error-Handler, die rohe Exception-Objekte direkt im Response-Body zurückgeben.

AppSafe erkennt ausführliche Fehler, indem es einen Pfad anfragt, der auf deiner Website nicht existieren sollte. Passt der Response-Body zu Mustern typischer Framework-Fehlerseiten — Python-Tracebacks, Node.js-Exception-Dumps, .NET-Exception-Details, Rails.root-Pfade oder Ähnliches —, wird der Befund mit mittlerem Schweregrad unter Fehlerbehandlung & Resilienz gemeldet.

Warum es wichtig ist

Ein Stack Trace verrät Sprache und Framework-Version, die interne Verzeichnisstruktur deiner App, die genaue Datei und Zeile, an der es scheiterte, und die Aufrufkette, die dorthin führte. Zusammen mit einer CVE-Datenbank verkürzen diese Informationen die Zeit von der Entdeckung bis zum gezielten Exploit — besonders bei bekannten Schwachstellen in bestimmten Framework- oder Bibliotheksversionen.

Debug-Seiten können außerdem Request-Daten, Teile von Umgebungsvariablen oder SQL-Fragmente in der gerenderten Ausgabe enthalten und so unbeabsichtigt Nutzereingaben oder serverinterne Werte preisgeben, die niemals einen Browser erreichen sollten.

So behebst du es

Niemals rohe Exceptions an den Client zurückgeben

Fange in Next.js-API-Routen und Route Handlers Exceptions explizit ab, protokolliere den vollständigen Fehler serverseitig und gib dem Aufrufer einen generischen Status zurück.

// app/api/example/route.ts
export async function GET() {
  try {
    // ... handler logic ...
  } catch (err) {
    console.error(err); // logs stack trace to your server/monitoring only
    return new Response("Internal Server Error", { status: 500 });
  }
}

Eine eigene Fehlerseite konfigurieren

Next.js rendert in Produktion pages/500.tsx (oder app/error.tsx im App Router) für unbehandelte Fehler. Fülle sie mit einer freundlichen Meldung — ohne technische Details — und binde einen Error-Monitoring-Dienst wie Sentry an, um die eigentliche Exception zu erfassen.

Auf Proxy-Ebene abfangen

Für jeden Fehler, der der App-Ebene entkommt, kann nginx alle 5xx-Antworten durch eine statische Seite ersetzen, bevor sie den Browser erreichen.

error_page 500 502 503 504 /50x.html;
location = /50x.html {
  root /usr/share/nginx/html;
  internal;
}

FAQ

Zeigt Next.js in Produktions-Builds Stack Traces an?

Das Entwicklungs-Overlay ist in Produktion bereits unterdrückt. Das eigentliche Risiko sind eigene Route Handlers oder API-Routen, die eine Exception abfangen und direkt in die Antwort serialisieren — etwas, das das Framework nicht von sich aus verhindert.

Wie prüft AppSafe auf ausführliche Fehler?

Es fragt eine URL an, die auf deiner Website nicht existiert, und durchsucht den Response-Body nach Phrasen wie 'Traceback (most recent call last)', 'Stack trace:', 'Unhandled Runtime Error', 'Exception Details:' und ähnlichen Markern aus Python-, Node.js-, PHP-, Java-, Ruby- und .NET-Frameworks.

Meine 404-Seite zeigt keinen Stack Trace, aber AppSafe hat sie trotzdem gemeldet. Warum?

Der Scanner gleicht eine breite Palette von Mustern ab, von denen einige auch in unvollständigen oder geschwärzten Fehlerantworten vorkommen. Prüfe, ob Exception-Klassennamen, interne Dateipfade oder Framework-Kennungen irgendwo im Body deiner 404- oder 500-Antwort auftauchen — selbst in einem Kommentar oder einem versteckten Element.

Ist deine App betroffen?

AppSafe prüft dies und Dutzende weitere Probleme in einem kostenlosen Scan.

Meine App gratis scannen

Aus dem Blog

PHP2Shell wird ausgenutzt: So prüfst du, ob deine App betroffen ist

Zwei kritische Bugs in PHP selbst gingen innerhalb weniger Tage von „Patch veröffentlicht“ zu „aktiv ausgenutzt“. So findest du heraus, ob etwas, das du hostest, eine betroffene Version nutzt — und was du heute dagegen tust.