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/SECURITY-HARDENING.md

@@ -271,6 +271,65 @@ gering, aber Audit-Bewertung fordert konsistente Header-Hygiene.
   nachvollziehbar, wer wann welches Passwort eingesehen hat
   (DSGVO + Insider-Threat).
 
+### Runde 13 – KRITISCH: IDOR auf Stressfrei-Email-Sub-Routes (Live-Pentest-Fund)
+
+Externer Pentest hat einen echten Credential-Exfiltration-Angriff erfolgreich
+durchgespielt: **als Portal-User von Kunde A komplette IMAP/SMTP-Klartext-
+Credentials von Kunde B abgreifen können**.
+
+**Angriffspfad:**
+1. Portal-Login als Kunde A
+2. `/api/stressfrei-emails/{id}` GET unterschied saubere Antworten:
+   - „E-Mail-Konto nicht gefunden" (ID existiert nicht)
+   - „Kein Zugriff auf diese Kundendaten" (ID existiert, gehört anderem)
+   → Information-Disclosure: Existenz von IDs durchprobierbar
+3. `/api/stressfrei-emails/{id}/credentials` GET ohne Ownership-Check →
+   IMAP/SMTP-Server, Username und **Klartext-Passwort** der fremden Mailbox
+
+**Root Cause:** der Haupt-Endpoint `GET /:id` hatte `canAccessStressfreiEmail`,
+die 8 Sub-Endpoints unter `:id/*` hatten **alle keinen** Ownership-Check —
+nur `authenticate + requirePermission('customers:read')`, was jeder Portal-User
+hat.
+
+**Betroffene Endpoints (alle gefixt):**
+- `GET /:id/credentials` ← **der kritische** (Klartext-Passwort + IMAP/SMTP)
+- `GET /:id/folder-counts`
+- `POST /:id/sync`
+- `POST /:id/send`
+- `POST /:id/enable-mailbox`
+- `POST /:id/sync-mailbox-status`
+- `POST /:id/reset-password`
+- `PUT /:id` (updateEmail im stressfreiEmail.controller)
+- `DELETE /:id` (deleteEmail)
+
+`canAccessStressfreiEmail(req, res, emailId)` als erste Zeile in jedem
+Controller. `canAccessResourceByCustomerId` emittiert bei Fehlversuch
+automatisch ein `ACCESS_DENIED MEDIUM`-Event ins Security-Monitoring → bei
+>5 Versuchen in 5 min wird ein `CRITICAL SUSPICIOUS`-Event erzeugt + Alert
+verschickt.
+
+**Live-verifiziert (Portal-User Kunde A versucht Email-ID von Kunde B):**
+
+| Endpoint | Vorher | Nachher |
+| --- | --- | --- |
+| `GET /:id/credentials` | 🚨 **200 mit Klartext-Passwort** | ✅ 403 |
+| `GET /:id/folder-counts` | 🚨 200 | ✅ 403 |
+| `POST /:id/sync` | 🚨 200 | ✅ 403 |
+| `POST /:id/send` | 🚨 fremde Mailbox zum Versand missbrauchbar | ✅ 403 |
+| `POST /:id/enable-mailbox` | 🚨 200 | ✅ 403 |
+| `POST /:id/sync-mailbox-status` | 🚨 200 | ✅ 403 |
+| `POST /:id/reset-password` | 🚨 fremdes Mailbox-Passwort zurücksetzbar | ✅ 403 |
+| `POST /:id/sync-forwarding` | (vorher schon gefixt) | ✅ 403 |
+| `PUT /:id` | 🚨 fremde Adresse änderbar | ✅ 403 |
+| `DELETE /:id` | 🚨 fremde Adresse löschbar | ✅ 403 |
+| Eigene Email-ID | (legitim) | ✅ 200/400 (durch) |
+| Security-Monitor | – | 8× `ACCESS_DENIED MEDIUM` geloggt ✅ |
+
+**Lehre:** wenn ein Haupt-Endpoint `:id` einen Ownership-Check hat, müssen
+**alle** Sub-Endpoints unter `:id/*` denselben Check haben. Eine fehlende
+Zeile am Anfang eines Sub-Controllers reicht für komplette Credential-
+Exfiltration über das Customer-Portal.
+
 ### Runde 12 – JWT raus aus localStorage (XSS-Resistenz)
 
 Externer Pentest: "JWT in `localStorage` (MITTEL)". Bei einer XSS-Lücke