Doku: URL-encoded Route-Params als by-design dokumentiert (R85-INFO)

docs/SECURITY-HARDENING.md

@@ -473,6 +473,37 @@ Vor jedem Launch mit echten Tokens probieren.
 
 ---
 
+## 📝 Bewusste Akzeptanz – URL-encoded Route-Parameter
+
+**Finding aus Pentest-Runde 85 (INFO, kein Security-Impact):**
+
+`/api/stressfrei-emails/%31/...` (URL-encoded `1`) liefert dieselbe
+Antwort wie `/api/stressfrei-emails/1/...` – die `requireIdParam`-
+Validierung mit `/^\d+$/` sieht die schon dekodierte Form, weil
+Express URL-Parameter **vor** dem Routing dekodiert.
+
+**Wir akzeptieren das als by-design:**
+
+1. RFC 3986 fordert genau dieses Verhalten: prozentual-codierte und
+   roh-Form derselben Zeichen müssen semantisch identisch behandelt
+   werden. `/1` und `/%31` ist HTTP-konform äquivalent.
+2. Ein nachträglicher Strict-Check auf `req.url` (roh) würde
+   legitime Clients brechen – Browser-Bookmarks mit URL-Encoding,
+   curl-Calls mit `--data-urlencode`, Proxy-Tools die URL-encoden,
+   Mobile-Clients mit kanonischer URL-Normalisierung.
+3. Der Pentester selbst bestätigt: **kein Security-Impact** – die ID
+   landet nach Dekodierung als gültige Zahl bei der gleichen
+   Auth-/IDOR-Logik, die auch für die rohe Form greift. Insbesondere
+   `canAccessStressfreiEmail` läuft identisch.
+4. Validierungs- und Access-Control-Kette ist nach der Dekodierung
+   identisch dicht – Auth, Ownership, Rate-Limit, alles greift gleich.
+
+**Code-Notiz:** kein Patch nötig. Diese Markdown-Sektion ist die
+einzige Dokumentation, damit das in zukünftigen Pentest-Runden nicht
+erneut als „offenes Finding" auftaucht.
+
+---
+
 ## 🧭 Wann ist „dicht" dicht?
 
 100 % gibt es nicht. Erreicht ist: