R192-01: Fehlermeldungen, die fuer Entwickler geschrieben sind

Befund der Pentesterin: PUT /users/:id {"roleIds":{}} gab 400 mit dem
rohen JS-Fehler "object is not iterable". Kein Wipe, keine Eskalation -
dieselbe Familie wie der Prisma-Pfad-Leak aus R190-01.

Zwei Ursachen. Erstens spreizte normalisiereRollenIds die roleIds ohne
Array.isArray-Guard. Zweitens reichte die Fehlerabbildung jede
error.message durch.

Die Unterscheidung laeuft jetzt ueber die Fehlerklasse, nicht ueber eine
Heuristik auf dem Text: Ein blankes Error werfen wir absichtlich und mit
einer Meldung fuer Menschen ("Der letzte Admin kann nicht..."). TypeError
und Verwandte sind Programmierfehler, Prisma-Fehler kommen von aussen -
beides sagt dem Aufrufer nichts Nuetzliches und einem Angreifer zu viel.
Unerwartetes wird 500 statt 400: Ein Eingabefehler-Code waere die naechste
Meldung, die sich falsch ausgibt.

Gegengeprueft, dass mit dem Leck nicht auch das Nuetzliche wegfaellt:
"Rolle kann nicht geloescht werden, da sie 1 Benutzern zugewiesen ist" ->
400, Systemrollen-Sperre -> 403 mit Klartext, Eskalation -> 403 mit den
konkret fehlenden Rechten. {}, "abc", 5, true als roleIds -> 400 "roleIds
muss eine Liste sein", Zustand unveraendert. R190-01/R191-01 gruen.

Offen und groesser als der Befund: Das Muster
`error instanceof Error ? error.message` steht 124-mal in 26
Controller-Dateien. Behoben ist es nur im Benutzer- und Rollenpfad.
Dieselbe Lage wie bei R188 und gehoert genauso zentral geloest.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

backend/src/controllers/user.controller.ts

@@ -655,21 +655,31 @@ function antworteAufRollenFehler(res: Response, error: unknown, fallback: string
     return;
   }
 
-  // Datenbankfehler NICHT durchreichen. Prisma haengt den vollstaendigen
-  // Aufruf samt Dateipfad an die Meldung - das ging bisher wortwoertlich an
-  // den Client. Nach aussen die allgemeine Auskunft, die Einzelheiten ins
-  // Serverprotokoll.
-  const name = error instanceof Error ? error.name : '';
-  if (name.startsWith('Prisma')) {
-    console.error(`[${fallback}]`, error);
-    res.status(400).json({ success: false, error: fallback } as ApiResponse);
+  // Ab hier gilt: Nur was wir SELBST formuliert haben, geht nach draussen.
+  //
+  // Vorher wurde jede `error.message` durchgereicht. Damit landete erst der
+  // vollstaendige Prisma-Aufruf samt Serverpfad beim Client, und danach der
+  // Wortlaut eines TypeError ("object is not iterable…") bei
+  // `{"roleIds":{}}` (Pentest R190-01 und R192-01). Beide Male dieselbe
+  // Ursache: eine Fehlermeldung, die fuer Entwickler geschrieben ist, an
+  // einen Empfaenger, fuer den sie nicht gedacht war.
+  //
+  // Die Unterscheidung ist die Fehlerklasse, keine Heuristik auf dem Text:
+  // Ein blankes `Error` werfen wir absichtlich und mit einer Meldung fuer
+  // Menschen ("Der letzte Admin kann nicht…"). TypeError, RangeError und
+  // Verwandte sind Programmierfehler, Prisma-Fehler kommen von aussen -
+  // beides sagt dem Aufrufer nichts Nuetzliches und dem Angreifer zu viel.
+  const istAbsichtlich = error instanceof Error && error.constructor === Error;
+  if (istAbsichtlich) {
+    res.status(400).json({ success: false, error: error.message } as ApiResponse);
     return;
   }
 
-  res.status(400).json({
-    success: false,
-    error: error instanceof Error ? error.message : fallback,
-  } as ApiResponse);
+  // Unerwartet: Das ist ein Serverfehler, kein Eingabefehler - und ein 400
+  // waere hier die naechste Meldung, die sich falsch ausgibt. Einzelheiten
+  // ins Protokoll, damit sie nicht verlorengehen.
+  console.error(`[${fallback}] unerwarteter Fehler:`, error);
+  res.status(500).json({ success: false, error: fallback } as ApiResponse);
 }
 
 export async function createRole(req: AuthRequest, res: Response): Promise<void> {

backend/src/services/rechte.service.ts

@@ -216,6 +216,12 @@ export function rechteDerHaken(haken: {
  * falsch als Eingabepruefung - zwei verschiedene Aufgaben.
  */
 export async function normalisiereRollenIds(roleIds: number[]): Promise<number[]> {
+  // Erst pruefen, dass es ueberhaupt eine Liste ist. Ohne das lief ein
+  // `{"roleIds":{}}` in einen TypeError beim Aufspreizen, und dessen
+  // Wortlaut ging an den Client (Pentest R192-01).
+  if (!Array.isArray(roleIds)) {
+    throw new UngueltigeEingabeError('roleIds muss eine Liste sein');
+  }
   const eindeutig = [...new Set(roleIds)];
   if (eindeutig.length === 0) return [];
   if (!eindeutig.every((id) => Number.isInteger(id) && id >= 1)) {