security: CRITICAL IDOR-Fix auf Stressfrei-Email-Sub-Routes

Pentest hat einen echten Credential-Exfiltration-Angriff erfolgreich
durchgespielt: als Portal-User von Kunde A komplette Klartext-IMAP/SMTP-
Zugangsdaten der Mailbox von Kunde B abgreifbar.

Root Cause: GET /api/stressfrei-emails/:id hatte canAccessStressfreiEmail-
Check, ALLE 8 Sub-Endpoints unter :id/* hatten nur `authenticate +
requirePermission('customers:read')` — was jeder Portal-User de facto hat.

Betroffene Controller (alle gefixt mit canAccessStressfreiEmail als erster
Zeile):

stressfreiEmail.controller.ts:
- updateEmail (PUT /:id)
- deleteEmail (DELETE /:id)
- resetPassword (POST /:id/reset-password)

cachedEmail.controller.ts:
- getMailboxCredentials (GET /:id/credentials) ← KRITISCHSTER, lieferte
  Klartext-IMAP/SMTP-Passwort + Server-Daten der fremden Mailbox
- getFolderCounts (GET /:id/folder-counts)
- syncAccount (POST /:id/sync)
- sendEmailFromAccount (POST /:id/send) — fremde Mailbox zum Versand
  missbrauchbar
- enableMailbox (POST /:id/enable-mailbox)
- syncMailboxStatus (POST /:id/sync-mailbox-status)

Security-Monitor: canAccessResourceByCustomerId emittiert bei jedem
Fehlversuch ein ACCESS_DENIED MEDIUM-Event. Threshold-Detection erzeugt
bei >5 Versuchen in 5 min ein CRITICAL SUSPICIOUS-Event + Sofort-Alert.

Live-verifiziert (Portal-User Kunde A versucht Email-ID von Kunde B):
- alle 8 Sub-Routes → HTTP 403
- eigene Email-ID → 200/400 (Ownership-Check OK)
- 8× ACCESS_DENIED MEDIUM im Security-Monitor

Doku in docs/SECURITY-HARDENING.md als Runde 13.

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

docs/todo.md

@@ -97,6 +97,29 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🚨 KRITISCH: IDOR auf Stressfrei-Email-Sub-Routes (Pentest-Fund)**
+  - **Realer Angriff erfolgreich durchgespielt**: Portal-User konnte über
+    `/api/stressfrei-emails/{id}/credentials` die kompletten Klartext-
+    IMAP/SMTP-Zugangsdaten der Mailbox eines anderen Kunden abrufen.
+  - **Root Cause**: der Haupt-Endpoint `GET /:id` hatte
+    `canAccessStressfreiEmail`-Check, die **8 Sub-Endpoints** unter
+    `:id/*` hatten alle KEINEN Ownership-Check (nur `authenticate +
+    requirePermission('customers:read')`, was Portal-User von Haus aus
+    haben).
+  - **Fix**: `canAccessStressfreiEmail(req, res, id)` als erste Zeile in
+    allen 9 betroffenen Controllern: `getMailboxCredentials`,
+    `getFolderCounts`, `syncAccount`, `sendEmailFromAccount`,
+    `enableMailbox`, `syncMailboxStatus`, `resetPassword`, `updateEmail`,
+    `deleteEmail`.
+  - **Security-Monitor**: `canAccessResourceByCustomerId` emittiert
+    bei jedem Fehlversuch automatisch ein `ACCESS_DENIED MEDIUM`-Event
+    → Threshold-Detection (>5 in 5 min) erzeugt `CRITICAL SUSPICIOUS` +
+    Sofort-Alert.
+  - **Live-verifiziert**: Portal-User Kunde A probiert Email-ID von
+    Kunde B durch alle 8 Sub-Routes → **alle 8× HTTP 403**, eigene
+    Email-ID kommt sauber durch (200/400), 8× `ACCESS_DENIED`-Events
+    im Security-Monitor.
+
 - [x] **🛡️ JWT-Tokens raus aus localStorage – Refresh-Cookie-Pattern**
   - Pentest-Finding „JWT in localStorage (MITTEL)": bei XSS könnte JS
     den Token klauen + alle Anbieter-Credentials abrufen. Lösung: