Aller au contenu

Tests RBAC — validation empirique et 3 bugs réels trouvés

Contexte

Script de test BackEnd/tests/rbac/test-rbac.sh créé le 2026-06-23 pour vérifier que chaque profil de ProjetESM/architecture/systeme-rbac-permissions accède uniquement aux routes autorisées — ni plus, ni moins. Simule 8 utilisateurs réels (comptes de test dédiés) qui se connectent via JWT et appellent les routes clés du backend, en vérifiant les codes HTTP (200 attendu / 403 attendu).

Contenu

Méthode

  • Comptes de test : un par profil (PSYCHOLOGUE, ASSISTANT_SOCIAL, MEAL_COMMUNAL, MEAL_NATIONAL, CHARGE_PROJET, BAILLEUR, ADMIN, SUPER_ADMIN), réinitialisables via BackEnd/prisma/create-comptes-test.ts.
  • Pour chaque profil : connexion → JWT → appel des routes autorisées (200 attendu) et des routes interdites (403 attendu).
  • Limitation connue : rate limiter auth à 10 requêtes/15 min par IP — lancer toutes les connexions en une seule passe pour éviter un blocage 429.

Résultat final : 66/66 tests passants — RBAC conforme

Mais ce résultat final masque 3 bugs réels trouvés uniquement parce que le test a été exécuté contre le vrai comportement, pas supposé conforme sur la seule base du seed :

v1 (2026-06-23) — faux positif initial sur BAILLEUR/MOBILISATION_LIRE : erreur dans le script de test lui-même, pas dans le RBAC (BAILLEUR possède légitimement cette permission).

v2 (2026-06-23) — erreur grave : PSYCHOLOGUE et ASSISTANT_SOCIAL avaient été à tort exclus de INDICATEUR_LIRE/INDICATEUR_SAISIR, alors que ce sont eux qui saisissent réellement les indicateurs au niveau communal. Corrigé dans seed.ts + appliqué en base + routeur frontend corrigé.

v3 (2026-06-26) — bug de scope de données, plus subtil que le RBAC lui-même : les requêtes de rapports filtraient systématiquement par idUtilisateur, quel que soit le rôle. Trois scopes distincts corrigés : - scope global (aucun filtre) pour SUPER_ADMIN/ADMIN/MEAL_NATIONAL/CHARGE_PROJET/DIRECTION - scope commune (communeCode) pour MEAL_COMMUNAL/COORDINATEUR_LOCAL - scope personnel (idUtilisateur) pour les agents de terrain

Plus un bug d'accès UI associé : la route /pilotage/saisies-equipe était protégée par ROLES_COORD_ET_ADMIN, bloquant à tort les agents de terrain qui devaient pourtant y accéder (scope commune propre) — déplacée vers ROLES_AVEC_PILOTAGE.

Point de vigilance non résolu

BAILLEUR a la permission RAPPORT_EXPORTER mais le scope actuel ne lui retourne que ses données personnelles (idUtilisateur), pas des agrégats nationaux. À trancher : le bailleur doit-il voir des agrégats consolidés ? Si oui, l'ajouter à ROLES_GLOBAL dans RapportsRepositoryPrisma.ts.

Décision / Conclusion

Les 3 corrections (v1 faux positif écarté, v2 permissions manquantes ajoutées, v3 bug de scope de données corrigé) confirment une leçon méthodologique : un RBAC qui "passe tous les tests" sur le papier (permissions correctement assignées) peut quand même exposer les mauvaises données si le scope de filtrage n'est pas testé indépendamment des permissions elles-mêmes. Le test de conformité RBAC doit couvrir à la fois "qui a le droit d'appeler la route" (403/200) ET "quelles données la route renvoie effectivement" (scope), pas seulement le premier.

À faire

  • Trancher le point de vigilance BAILLEUR (agrégats nationaux ou données personnelles).
  • Resynchroniser seed.ts avec les permissions ajoutées directement en base (INSERTION_MODIFIER, CONCERTATION_GERER) pour éviter une régression au prochain db push.
  • Relancer ce script après toute modification touchant une route, le middleware autoriser.middleware.ts, les permissions d'un profil, ou avant tout déploiement manuel.

Liens connexes