Aller au contenu

PD-23 — Acceptabilité

Objectif

Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.

Périmètre de vérification

La revue d’acceptabilité vérifie explicitement :

  • la conformité stricte à la spécification fonctionnelle
  • le respect de tous les invariants applicables
  • la couverture des scénarios de test définis
  • l’absence d’incohérences, oublis ou régressions

Écarts identifiés

Chaque écart constaté est documenté et classé selon sa gravité.

Classification des écarts

Niveau Définition
BLOQUANT Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec
MAJEUR Fonction incomplète, comportement non conforme mais sans rupture de sécurité
MINEUR Détail, dette acceptable, amélioration non critique

Détail des écarts

ID Description Référence Gravité
E-01 Pas d’envoi réel du mail de validation : outbox créée mais aucun worker/mailer ni lien de validation, TODO laissé dans register() ⇒ le flux spec (§6.1 étape 4, invariant 9) n’est pas réalisé, l’activation par email est impossible. auth.service.ts:77-134 (TODO en post-commit), absence de consumer email_outbox RÉSOLU
E-02 Anti-automatisation non conforme à l’invariant 11 : RateLimitGuard est un limitateur mémoire temporaire, seuils ad hoc, aucun défi CAPTCHA ni règles explicites ; la protection anti-abus requise par la spec n’est pas implémentée. rate-limit.guard.ts:8-98 RÉSOLU
E-03 Paramètres SRP du payload ignorés/non persistés : srp_params acceptés en DTO mais ni validés fonctionnellement ni stockés, et le service SRP force le groupe 3072. La spec (§5.2, invariant 3) impose la prise en compte/persistance des paramètres SRP fournis. register.dto.ts; auth.service.ts:95-131; user.entity.ts (pas de champ); srp.service.ts (groupe figé) RÉSOLU
E-04 Traçabilité incomplète des erreurs de validation : les 400 dus aux validations DTO ou validateClientRegistration ne sont pas audités, contrairement à l’invariant 7 et au plan (§6.1). Seuls certains guards loggent. auth.service.ts (validation avant try/catch, aucun log); pipeline Nest validation RÉSOLU
E-05 Endpoint de purge non protégé : /auth/purge/expired est exposé sans AdminAuthGuard (TODO), permettant la suppression de comptes/traçes par appel non authentifié ; risque sécurité / conformité (invariant 10/12). account-purge.controller.ts:54-90 RÉSOLU
E-06 Anti-énumération non robuste sur collision unique : une violation de contrainte UNIQUE en base (ex. course concurrente) remonte en 500 et révèle un comportement différencié, contraire à l’invariant 8 et aux cas d’erreur déterministes de la spec (§7). auth.service.ts:120-171 (aucun rattrapage des erreurs de contrainte) RÉSOLU
E-07 Tests obsolètes vs spécification : auth.controller.spec.ts attend un champ password et ne couvre ni guards ni anti-énumération, laissant les scénarios PD-23 non testés. auth.controller.spec.ts:35-68 RÉSOLU

[2025-12-27] — Suivi E-01

  • Statut précédent : BLOQUANT
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Worker d’envoi opérationnel : EmailSenderService (poll cron 10s) lit email_outbox, rend le template validation_email et envoie via nodemailer SMTP TLS (Infomaniak) avec credentials fournis par VaultService.getSmtpCredentials() ou variables d’environnement.
  • Outbox alimentée en transaction : AuthService.register() insère validationToken (TTL 1h) + templateData (token, expiresAt) dans email_outbox; le template construit le lien de validation.
  • Module chargé : EmailModule (avec VaultModule, ScheduleModule) importé dans AppModule; tests email-sender.service.spec.ts passent.
  • Référence vérification :
  • src/modules/auth/auth.service.ts (outbox, token 1h)
  • src/modules/email/services/email-sender.service.ts (cron, SMTP, retries)
  • src/modules/email/services/email-template.service.ts (lien /validate-email?token=…)
  • src/modules/vault/vault.service.ts#getSmtpCredentials
  • src/modules/email/email.module.ts ; src/app.module.ts
  • Tests : src/modules/email/services/email-sender.service.spec.ts

[2025-12-27] — Suivi E-02

  • Statut précédent : BLOQUANT
  • Statut actuel : PARTIELLEMENT RÉSOLU
  • Justification factuelle :
  • Rate limiting désormais distribué via Redis (RateLimitService), appelé par RateLimitGuard sur /auth/register; configuration dédiée rate-limit.config.ts; tests avec ioredis-mock couvrent la logique.
  • Reste non conforme à l’invariant 11 : aucun défi CAPTCHA ni règles anti-abus définies (seuils/fenêtres/codes) implémentés, la protection attendue reste incomplète.
  • Référence vérification :
  • src/modules/auth/services/rate-limit.service.ts ; src/modules/auth/guards/rate-limit.guard.ts
  • src/config/rate-limit.config.ts ; src/modules/auth/auth.module.ts (injection guard/service)
  • Tests : src/modules/auth/services/rate-limit.service.spec.ts

[2025-12-27] — Suivi E-02 (complément)

  • Statut précédent : PARTIELLEMENT RÉSOLU
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Anti-automatisation complète : rate limiting Redis avec seuils soft/hard, état CAPTCHA_REQUIRED et BLOCKED.
  • CAPTCHA Cloudflare Turnstile via CaptchaService, guard RateLimitGuard gère les 3 états et valide captchaToken ; DTO RegisterDto accepte captchaToken.
  • Audits ajoutés (REGISTRATION_CAPTCHA_REQUIRED, REGISTRATION_CAPTCHA_FAILED, REGISTRATION_RATE_LIMITED).
  • Tests unitaires/guard/captcha couvrent les transitions et validations.
  • Référence vérification :
  • src/modules/auth/services/captcha.service.ts ; src/modules/auth/services/rate-limit.service.ts
  • src/modules/auth/guards/rate-limit.guard.ts ; src/modules/auth/dto/register.dto.ts
  • Tests : src/modules/auth/services/captcha.service.spec.ts ; src/modules/auth/services/rate-limit.service.spec.ts ; src/modules/auth/guards/rate-limit.guard.spec.ts

[2025-12-27] — Suivi E-06

  • Statut précédent : MINEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Gestion explicite des violations UNIQUE (code PG 23505) en anti-énumération : délai, audit REGISTRATION_DUPLICATE, réponse 200 identique.
  • Test ajouté couvrant le cas de course.
  • Référence vérification :
  • src/modules/auth/auth.service.ts (gestion UNIQUE 23505)
  • Tests : src/modules/auth/auth.service.spec.ts (“UNIQUE constraint violation”)

[2025-12-27] — Suivi E-07

  • Statut précédent : MINEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Tests auth.controller.spec.ts alignés sur le payload SRP (srpSalt/srpVerifier, réponse { status: 'OK' }), couvrant les guards et anti-énumération.
  • Référence vérification :
  • src/modules/auth/auth.controller.spec.ts (sections register test mises à jour)

[2025-12-27] — Suivi E-03

  • Statut précédent : MAJEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Les paramètres SRP reçus (srp_params) sont mappés/validés via mapSrpParamsToVersion() et stockés (srpVersion) lors de la création de l’utilisateur.
  • Groupe/hash/KDF non supportés déclenchent explicitement une BadRequest; groupe 3072/ SHA3-256/Argon2id accepté (version 1).
  • Tests ajoutés couvrant le mapping/erreurs.
  • Référence vérification :
  • src/modules/auth/auth.service.ts (mapSrpParamsToVersion, stockage srpVersion)
  • Tests : src/modules/auth/auth.service.spec.ts (describe srpParams handling)

[2025-12-27] — Suivi E-04

  • Statut précédent : MAJEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Filtre ValidationErrorFilter applique un audit des 400 (ValidationPipe, validateClientRegistration, erreurs BadRequest) avec hashing des emails (pas de PII en clair) et métadonnées.
  • Filtre appliqué au contrôleur AuthController via @UseFilters.
  • Tests unitaires du filtre ajoutés.
  • Référence vérification :
  • src/modules/auth/filters/validation-error.filter.ts
  • src/modules/auth/auth.controller.ts (@UseFilters)
  • Tests : src/modules/auth/filters/validation-error.filter.spec.ts

[2025-12-27] — Suivi E-05

  • Statut précédent : MAJEUR
  • Statut actuel : RÉSOLU
  • Justification factuelle :
  • Endpoint /auth/purge/* protégé par InternalApiGuard (clé API X-Internal-Api-Key, réseaux autorisés contrôlés; en production, clé requise si configurée).
  • Guard audite les accès refusés; appliqué au AccountPurgeController.
  • Tests unitaires du guard ajoutés.
  • Référence vérification :
  • src/modules/auth/guards/internal-api.guard.ts
  • src/modules/auth/controllers/account-purge.controller.ts (@UseGuards)
  • Tests : src/modules/auth/guards/internal-api.guard.spec.ts

Conclusion d’acceptabilité

✅ ACCEPTÉ — Tous les écarts E-01 à E-07 sont résolus.

Historique des verdicts

Date Verdict Commentaire
2025-12-27 ⛔ REFUSÉ E-01 BLOQUANT (pas d’envoi email), E-02 BLOQUANT (anti-automatisation non conforme)
2025-12-27 ⛔ REFUSÉ E-01 résolu (envoi email via outbox/SMTP), E-02 partiellement résolu (pas de CAPTCHA/règles anti-abus), E-03 à E-07 ouverts
2025-12-27 ✅ ACCEPTÉ E-01 à E-07 résolus (anti-automatisation + CAPTCHA, SRP params stockés, audit 400, purge sécurisée, anti-énumération UNIQUE, tests alignés)