Skip to main content
Informative Fehlermeldungen sind wichtig, weil Benutzer verstehen müssen, was sie tun können. Gleichzeitig dürfen Fehlermeldungen keine internen Details preisgeben.

​
Problem

Zu detaillierte Fehlermeldungen helfen Angreifern. Zu unklare Fehlermeldungen helfen Benutzern nicht. Schlecht sind Meldungen mit:
  • Stack Traces
  • SQL-Fehlern
  • internen Pfaden
  • Klassennamen
  • Secrets
  • Hinweisen, ob ein Benutzerkonto existiert

​
Lösung

Eine gute Fehlermeldung ist:
  • verständlich
  • handlungsorientiert
  • konsistent
  • ohne Stack Trace, SQL, Pfade oder Secrets
  • für Login und Passwort-Reset bewusst generisch

​
Beispiele

SchlechtWarum schlecht?Besser
SQLSTATE[42S02]: Table users not foundVerrät DatenbankdetailsDie Anfrage konnte nicht verarbeitet werden.
User max@example.com does not existErmöglicht User EnumerationE-Mail oder Passwort ist ungültig.
NullReferenceException in /var/www/auth/reset.php:42Verrät Pfade und ImplementierungDer Link konnte nicht geprüft werden.
FehlerZu unklar für BenutzerDas Passwort muss mindestens 12 Zeichen lang sein.

​
Best-Practice-Vergleich nach SonarSource

SonarSource empfiehlt robustes Error Handling, damit Anwendungen zuverlässig, sicher und benutzerfreundlich bleiben. Beim Vergleich einer vorhandenen Anwendung kannst du diese Checkliste verwenden.
Best PracticePrüffrageVerbesserung
Fehler nicht ignorierenGibt es leere catch-Blöcke?Fehler behandeln oder bewusst weiterwerfen
Informative MeldungenVersteht der Benutzer den nächsten Schritt?Sichere, konkrete Meldungen schreiben
Keine internen DetailsWerden Stack Traces oder SQL-Fehler angezeigt?Details nur intern loggen
Recoverable vs. unrecoverable trennenWird jeder Fehler gleich behandelt?Retry/Fallback nur bei recoverable errors
Zentrales HandlingGibt es viele uneinheitliche Fehlerpfade?Middleware oder zentrale Error Handler nutzen
Logging und MonitoringWerden relevante Fehler protokolliert?Kontext loggen, Alerting für kritische Fehler
TestsWerden Fehlerfälle getestet?Unit- und Integrationstests für Fehlerpfade ergänzen

​
Beispiel

// Schlecht: Fehler verschwindet.
try {
  await resetPassword(email);
} catch {}

// Besser: sicher für Benutzer, nützlich für Betrieb.
try {
  await resetPassword(email);
} catch (error) {
  logger.warn("Password reset failed", { emailHash: hash(email), error });
}

showMessage("Falls ein Konto existiert, senden wir dir einen Link.");

​
Merksatz

Zeige Benutzern, was sie tun können. Logge intern, was technisch passiert ist. Verrate Angreifern keine Details.