PD-105 — Review Sécurité v2
Date : 2026-02-10 Reviewer : ChatGPT (gov-factual) Contexte : Post-corrections ECT-03 (validation Zod)
Résumé
| Critère | Statut |
| Validation Zod | ⚠️ |
| Fallback sécurisé | ✅ |
| Protection injection | ⚠️ |
| Logs sécurisés | ⚠️ |
Verdict : ⚠️ RÉSERVES
Audit de la validation ECT-03
| Aspect | Évaluation | Commentaire |
| Schema Zod | ⚠️ Partiel | Bonne base (validation runtime, safeParse, pas de coercion implicite), mais schéma trop permissif: tous les champs sont optionnels, pas de contraintes de format/longueur (targetId, eventType, notificationId) et passthrough() accepte des clés non contrôlées. |
| Fallback | ✅ Correct | En cas d'échec de parsing, retour {} évite crash et force un comportement fail-safe (pas d'exploitation directe via exception). |
| Passthrough | ⚠️ Risqué | passthrough() peut laisser transiter des champs inattendus; si ces données sont ensuite historisées, loggées ou propagées, cela ouvre la porte à pollution de données et non-respect potentiel de INV-105-07. |
Vulnérabilités identifiées
| ID | Description | Gravité | Fichier |
| SEC-105-ECT03-01 | Schéma trop permissif (.passthrough() + champs optionnels) : accepte des payloads non conformes métier avec données arbitraires. | Medium | handlers.ts |
| SEC-105-ECT03-02 | Absence de validation sémantique sur targetId/eventType/notificationId (format, longueur, charset) : risque d'injection logique (navigation/résolution) et DoS par chaînes volumineuses. | Medium | handlers.ts |
| SEC-105-ECT03-03 | Dualité content-available (string) / contentAvailable (boolean) sans normalisation stricte : ambiguïté possible dans la logique silent/alert. | Low | handlers.ts |
| SEC-105-ECT03-04 | Log d'erreurs de validation en clair (console.warn) : faible risque d'exposition en production (métadonnées d'erreur, fréquence d'échecs). | Low | handlers.ts |
Recommandations
- Remplacer
.passthrough() par .strict() ou .strip() pour bloquer/supprimer les clés non attendues. - Ajouter des contraintes Zod:
.max(...), .regex(...), z.enum(...) pour eventType, UUID v4 strict pour notificationId. - Normaliser
content-available/contentAvailable vers un seul champ canonical (booléen), avec conversion contrôlée et rejet explicite des valeurs ambiguës. - Implémenter un allowlist métier des
eventType et valider targetId par type de cible avant toute navigation/résolution. - Sanitiser les logs (pas d'objets d'erreur complets en prod) + rate-limit des warnings pour éviter le bruit exploitable.
- Vérifier explicitement que seules les clés autorisées sont historisées afin de garantir INV-105-07.
Comparaison v1 vs v2
| Aspect | v1 (avant) | v2 (après) |
| Validation payload | ❌ as NotificationData (unsafe cast) | ✅ Zod safeParse |
| Crash sur payload malformé | ❌ Possible | ✅ Fallback sécurisé |
| Protection injection | ❌ Aucune | ⚠️ Partielle |
| Logging erreurs | ❌ Non contrôlé | ⚠️ Améliorable |
Progression : Amélioration significative de la posture sécurité, réserves mineures pour itérations futures.