`errors.validation` est injouable dans toute application dont les routes POST sont gardées #118

New issue

Closed

opened 2026-10-06 14:14:01 +00:00 by nicolas-fryder · 0 comments

nicolas-fryder commented

2026-10-06 14:14:01 +00:00

Owner

Le manque

ContexteErrors déclare routeValidation :

/** Une route POST qui valide un corps ; un `{}` doit être refusé. */
routeValidation?: string

…mais aucun moyen de s'authentifier. ContextePlatform, lui, en a un :

/** En-têtes ajoutés aux appels de `routeValidation` (cookie de session, clé API). */
enTetes?: Record<string, string>

Ce qui arrive

Sur nuage, toutes les routes sont gardées. En fournissant routeValidation: '/api/viewers', le contrôle part sans identité et conclut :

[bloquant] errors.validation (/api/viewers)
  /api/viewers avec {} rend 401 au lieu de 422
[bloquant] errors.validation (/api/viewers)
  /api/viewers : code UNAUTHENTICATED au lieu de VALIDATION
[bloquant] errors.validation (/api/viewers)
  /api/viewers : errors[] vide ou absent

Trois constats bloquants sur un corps qu'il n'a jamais fait valider : la requête s'est arrêtée à la garde. Le même diagnostic vaudrait pour n'importe quel satellite dont aucune route POST n'est publique — ce qui est le cas recherché, pas une exception.

Et c'est un faux négatif particulièrement coûteux : il dit que l'enveloppe de validation est cassée alors qu'elle fonctionne. platform.validation, qui frappe la MÊME route avec enTetes, passe.

Correction proposée

Ajouter enTetes?: Record<string, string> à ContexteErrors, de la même forme et avec le même commentaire que dans ContextePlatform, et le passer aux appels de validation (et de codeFerme, qui frappe aussi routeValidation).

Accessoirement : quand routeValidation rend 401 ou 403, le contrôle pourrait le dire comme tel — « la route est gardée et aucune identité n'a été fournie » — plutôt que de l'imputer au filtre d'erreurs. Un message qui désigne la mauvaise cause coûte une demi-heure à chaque fois.

En attendant

Nuage ne fournit pas errors.routeValidation et garde une dispense datée qui dit pourquoi. La validation du corps reste éprouvée par platform.validation.

Contexte

Relevé pendant le rétrofit du socle sur nuage (0.14.0), en câblant les fixtures de conformité — 26 dispenses ramenées à 18 dans la foulée. Même journée que #115, #116 et #117.

## Le manque `ContexteErrors` déclare `routeValidation` : ```ts /** Une route POST qui valide un corps ; un `{}` doit être refusé. */ routeValidation?: string ``` …mais **aucun moyen de s'authentifier**. `ContextePlatform`, lui, en a un : ```ts /** En-têtes ajoutés aux appels de `routeValidation` (cookie de session, clé API). */ enTetes?: Record<string, string> ``` ## Ce qui arrive Sur nuage, toutes les routes sont gardées. En fournissant `routeValidation: '/api/viewers'`, le contrôle part sans identité et conclut : ``` [bloquant] errors.validation (/api/viewers) /api/viewers avec {} rend 401 au lieu de 422 [bloquant] errors.validation (/api/viewers) /api/viewers : code UNAUTHENTICATED au lieu de VALIDATION [bloquant] errors.validation (/api/viewers) /api/viewers : errors[] vide ou absent ``` Trois constats bloquants sur un corps qu'il n'a jamais fait valider : la requête s'est arrêtée à la garde. Le même diagnostic vaudrait pour n'importe quel satellite dont aucune route POST n'est publique — ce qui est le cas recherché, pas une exception. Et c'est un faux négatif particulièrement coûteux : il dit que l'enveloppe de validation est cassée alors qu'elle fonctionne. `platform.validation`, qui frappe la MÊME route avec `enTetes`, passe. ## Correction proposée Ajouter `enTetes?: Record<string, string>` à `ContexteErrors`, de la même forme et avec le même commentaire que dans `ContextePlatform`, et le passer aux appels de `validation` (et de `codeFerme`, qui frappe aussi `routeValidation`). Accessoirement : quand `routeValidation` rend 401 ou 403, le contrôle pourrait le dire comme tel — « la route est gardée et aucune identité n'a été fournie » — plutôt que de l'imputer au filtre d'erreurs. Un message qui désigne la mauvaise cause coûte une demi-heure à chaque fois. ## En attendant Nuage ne fournit pas `errors.routeValidation` et garde une dispense datée qui dit pourquoi. La validation du corps reste éprouvée par `platform.validation`. ## Contexte Relevé pendant le rétrofit du socle sur nuage (0.14.0), en câblant les fixtures de conformité — 26 dispenses ramenées à 18 dans la foulée. Même journée que #115, #116 et #117.

nicolas-fryder referenced this issue from a commit

2026-10-06 14:42:06 +00:00

Les contrôles de conformité s'authentifient sur une route gardée

nicolas-fryder referenced this issue

2026-10-06 14:46:42 +00:00

Quatorze tickets épuisés : auth, corps bornés, knip, eqs check, rétrofit des comptes #119

nicolas-fryder closed this issue

2026-10-07 06:10:10 +00:00