[0m
build · gpt-5.3-codex [0m
PD-105 — Revue Sécurité¶
Résumé¶
| Critère | Statut |
|---|---|
| Token APNs | ⚠️ |
| Validation payloads | ⚠️ |
| Navigation sécurisée | ✅ |
| Logging | ⚠️ |
| DoS protection | ⚠️ |
Verdict : ⚠️ RÉSERVES
Vulnérabilités identifiées¶
| ID | Description | Gravité | Exploitabilité |
|---|---|---|---|
| SEC-01 | Validation payload insuffisante : data est casté (as NotificationData) sans validation runtime stricte (schéma, longueur, caractères autorisés, enum stricte). Un payload malformé peut provoquer comportements inattendus (navigation incorrecte, erreurs métier, pollution store). | MOYENNE | Facile |
| SEC-02 | Absence de contrôle d’authenticité applicative du message : le code ne montre ni signature applicative (HMAC/JWT), ni nonce/timestamp anti-rejeu dans le payload. APNs garantit le canal Apple→device, mais pas une validation métier supplémentaire côté app. | HAUTE | Moyenne |
| SEC-03 | Logging potentiellement sensible : console.error(..., error) peut exposer des objets d’erreur contenant token, endpoint, metadata push ou IDs corrélables en debug/telemetry. | MOYENNE | Facile |
| SEC-04 | DoS logique par flood notifications : MAX_NOTIFICATIONS=100 limite le stockage, mais pas le traitement entrant (pas de rate-limit local, pas de déduplication forte par notificationId, pas de backoff). Risque de saturation UX/batterie/CPU. | MOYENNE | Moyenne |
| SEC-05 | Dépendance à eventType texte : mapping whitelist est une bonne base, mais l’absence de normalisation stricte de targetId/eventType (taille max, pattern, cohérence métier) peut permettre abus applicatifs (navigation vers ressource non autorisée si contrôles aval faibles). | MOYENNE | Moyenne |
Recommandations¶
| ID | Recommandation | Priorité |
|---|---|---|
| REC-01 | Ajouter une validation runtime stricte du payload (Zod/Yup/valibot) : champs requis, eventType enum fermée, targetId UUID strict, tailles max, rejet explicite des champs inconnus. | P1 |
| REC-02 | Mettre en place une authenticité applicative du payload : signature serveur (HMAC/JWS), iat/exp, nonce unique, vérification anti-rejeu côté app + backend. | P1 |
| REC-03 | Renforcer la navigation : conserver la whitelist actuelle, mais ajouter une autorisation métier avant navigation (vérifier que targetId appartient bien à l’utilisateur courant via API/store sécurisé). | P1 |
| REC-04 | Durcir le logging : suppression/masquage (token[0..6]...), pas de dump d’objets erreur bruts en prod, centraliser via logger avec redaction automatique des clés sensibles. | P1 |
| REC-05 | Ajouter protections DoS : throttling local, déduplication par notificationId, limite de traitement par fenêtre temporelle, rejet payload > taille attendue, métriques d’anomalie. | P2 |
| REC-06 | Pour iOS natif, vérifier l’usage du bon token selon architecture : ExpoPushToken (Expo service) vs token APNs direct (getDevicePushTokenAsync) et documenter le modèle de confiance. | P2 |
Points positifs observés : - Mapping EVENT_SCREEN_MAP agit comme whitelist de routes (bon contrôle anti-injection de route brute). - Validation UUID existante en stockage local. - Limitation de rétention/volume (MAX_NOTIFICATIONS, RETENTION_DAYS) réduit l’impact persistance.