[Mineur] Rôles : aucune validation du nom et permission acceptant n'importe quel entier #120

New issue

Closed

opened 2026-10-28 10:32:12 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:32:12 +00:00

Owner

Gravité : Mineur
Rapports QA d'origine : ADMIN-09, ADMIN-10, SECURITY_UX-13

Nom vide, espaces, 10 000 caractères (rend /admin inutilisable), HTML, doublon de casse ; PATCH /roles/{id}/permission accepte -1 ou 99999. Voir aussi #69.

Détails des rapports

[ADMIN-09] Création / renommage de rôle : aucune validation côté API (vide, espaces, 300 caractères, HTML, doublon de casse) — Gravité : Mineur

Où : POST /api/roles, PATCH /api/roles/{id}/name
Obtenu : POST /roles avec "" -> 200 (rôle au nom vide créé), " " -> 200, nom de 300 caractères -> 200, qa_admin_<img src=x onerror=alert(1)> -> 200, QA_ADMIN_R1 à côté de qa_admin_r1 -> 200, "qa_admin_r1 " -> 200. Seul le doublon exact renvoie 409. L'UI limite à 1-20 caractères (modale), l'API non.
PATCH /roles/{id}/name avec le nom actuel du même rôle -> 409 "already used by an other role" (devrait être un no-op) ; avec "" -> 409 "'' already used" (parce que le rôle vide existe déjà).
Conséquence visible : un rôle de 10 015 caractères (créé par un autre agent QA via l'API) rend /admin/roles et /admin/users inutilisables : tableau large de ~89 000 px, colonnes de permissions et Actions rejetées hors écran (scroll horizontal), <select> de rôle élargi dans /admin/users. Un nom vide produit une ligne sans libellé.
Cause probable : backend/API/Roles/Create/CreateRoleQuery.cs, backend/API/Roles/Patch/PatchRoleNameQuery.cs (comparaison r.Name == name sensible à la casse, aucune validation, check_name inclut le rôle lui-même).

[ADMIN-10] `PATCH /roles/{id}/permission` accepte n'importe quel entier (-1, 99999, bits inconnus) — Gravité : Mineur

Obtenu : 200 pour -1, 99999, 2147483647, 65... et la valeur est stockée telle quelle (GET /roles renvoie -1). -1 active tous les bits, y compris de futures permissions.
Cause probable : backend/API/Roles/Patch/PatchRolePermEndpoint.cs:12 : cast (Perms)permission sans masque.

[SECURITY_UX-13] Création de rôles sans aucune validation du nom (vide, blanc, 10 000 caractères) — Gravité : Mineur

Où : POST /api/roles (corps = chaîne JSON brute)
Obtenu : un rôle dont le nom fait 10 000 caractères est créé (200) ; la liste GET /roles contient déjà des rôles au nom "" et " " (créés par un test précédent d'un autre agent ou manuellement) ; un nouveau POST avec "" répond 409 « already used », donc le nom vide a été accepté une première fois. PATCH /roles/{id}/permission accepte aussi -1 (tous les bits, y compris non définis).
Cause probable : backend/API/Roles/Create/CreateRoleEndpoint.cs:11 ([FromBody] string name sans [Length]/[Required]), Roles/Patch/PatchRolePermEndpoint.cs:12.

Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes.

**Gravité :** Mineur **Rapports QA d'origine :** ADMIN-09, ADMIN-10, SECURITY_UX-13 Nom vide, espaces, 10 000 caractères (rend /admin inutilisable), HTML, doublon de casse ; `PATCH /roles/{id}/permission` accepte -1 ou 99999. Voir aussi #69. ## Détails des rapports <details><summary>[ADMIN-09] Création / renommage de rôle : aucune validation côté API (vide, espaces, 300 caractères, HTML, doublon de casse) — Gravité : Mineur</summary> - Où : `POST /api/roles`, `PATCH /api/roles/{id}/name` - Obtenu : `POST /roles` avec `""` -> 200 (rôle au nom vide créé), `" "` -> 200, nom de 300 caractères -> 200, `qa_admin_<img src=x onerror=alert(1)>` -> 200, `QA_ADMIN_R1` à côté de `qa_admin_r1` -> 200, `"qa_admin_r1 "` -> 200. Seul le doublon exact renvoie 409. L'UI limite à 1-20 caractères (modale), l'API non. `PATCH /roles/{id}/name` avec le nom actuel du même rôle -> 409 "already used by an other role" (devrait être un no-op) ; avec `""` -> 409 "'' already used" (parce que le rôle vide existe déjà). - Conséquence visible : un rôle de 10 015 caractères (créé par un autre agent QA via l'API) rend /admin/roles et /admin/users inutilisables : tableau large de ~89 000 px, colonnes de permissions et Actions rejetées hors écran (scroll horizontal), `<select>` de rôle élargi dans /admin/users. Un nom vide produit une ligne sans libellé. - Cause probable : `backend/API/Roles/Create/CreateRoleQuery.cs`, `backend/API/Roles/Patch/PatchRoleNameQuery.cs` (comparaison `r.Name == name` sensible à la casse, aucune validation, `check_name` inclut le rôle lui-même). </details> <details><summary>[ADMIN-10] `PATCH /roles/{id}/permission` accepte n'importe quel entier (-1, 99999, bits inconnus) — Gravité : Mineur</summary> - Obtenu : 200 pour `-1`, `99999`, `2147483647`, `65`... et la valeur est stockée telle quelle (`GET /roles` renvoie `-1`). `-1` active tous les bits, y compris de futures permissions. - Cause probable : `backend/API/Roles/Patch/PatchRolePermEndpoint.cs:12` : cast `(Perms)permission` sans masque. </details> <details><summary>[SECURITY_UX-13] Création de rôles sans aucune validation du nom (vide, blanc, 10 000 caractères) — Gravité : Mineur</summary> - Où : `POST /api/roles` (corps = chaîne JSON brute) - Obtenu : un rôle dont le nom fait 10 000 caractères est créé (200) ; la liste `GET /roles` contient déjà des rôles au nom `""` et `" "` (créés par un test précédent d'un autre agent ou manuellement) ; un nouveau POST avec `""` répond 409 « already used », donc le nom vide a été accepté une première fois. `PATCH /roles/{id}/permission` accepte aussi `-1` (tous les bits, y compris non définis). - Cause probable : `backend/API/Roles/Create/CreateRoleEndpoint.cs:11` (`[FromBody] string name` sans `[Length]`/`[Required]`), `Roles/Patch/PatchRolePermEndpoint.cs:12`. </details> --- _Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes._

asventi added the

bug

groupe/input-validation

labels

2026-10-28 10:44:19 +00:00