[Critique] La whitelist de rôles d'une catégorie n'est pas appliquée par l'API des messages #85

New issue

Closed

opened 2026-10-28 10:31:49 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:31:49 +00:00

Owner

Gravité : Critique
Rapports QA d'origine : CHAT-18

Include(Category) sans ThenInclude(RolesWhitelist) : pour un channel synchronisé avec sa catégorie, un Member hors whitelist lit et écrit.

Détails des rapports

[CHAT-18] La whitelist de rôles d'une CATÉGORIE n'est pas appliquée par l'API des messages (channel "synchronisé") — Gravité : Critique

Où : GET/POST /api/channels/{id}/messages (+ PUT/DELETE/ack/SignalR) sur un channel avec categorySync: true dont la catégorie a une whitelist.
Étapes : 1. admin crée la catégorie qa_chat_wlcat2 avec whitelistRoles: ["qa_chat_wl"] (la réponse confirme le rôle), puis un channel categorySync: true dedans. 2. carol (rôle qa_chat_wl) y poste "cat-secret". 3. bob (Member, rôle absent de la whitelist) : GET /channels/<id>/messages puis POST.
Attendu : 401 pour bob. Obtenu : 200 avec "cat-secret" et POST 201 (bob peut lire et écrire). Idem avec un channel non synchronisé (whitelist de channel vide = ouvert, normal). La sidebar de bob masque pourtant le channel (filtre front), donc l'UI donne une fausse impression de protection.
Cause probable : Channel.IsWhitelisted (backend/API/Channels/Channel.cs) lit Category.RolesWhitelist, mais les commandes/requêtes de messages font .Include(c => c.Category) sans .ThenInclude(c => c.RolesWhitelist).ThenInclude(r => r.Role) (ex. Messages/List/ListMessagesQuery.cs:22, Create/CreateMessageCommand.cs, Update, Delete, Get, Ack) : la collection est vide => Count == 0 => accès autorisé. Les diffusions SignalR NewMessage/UpdateMessage/RemoveMessage (même filtre) sont donc envoyées aux non-autorisés.

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é :** Critique **Rapports QA d'origine :** CHAT-18 `Include(Category)` sans `ThenInclude(RolesWhitelist)` : pour un channel synchronisé avec sa catégorie, un Member hors whitelist lit et écrit. ## Détails des rapports <details><summary>[CHAT-18] La whitelist de rôles d'une CATÉGORIE n'est pas appliquée par l'API des messages (channel "synchronisé") — Gravité : Critique</summary> - Où : `GET/POST /api/channels/{id}/messages` (+ PUT/DELETE/ack/SignalR) sur un channel avec `categorySync: true` dont la catégorie a une whitelist. - Étapes : 1. admin crée la catégorie `qa_chat_wlcat2` avec `whitelistRoles: ["qa_chat_wl"]` (la réponse confirme le rôle), puis un channel `categorySync: true` dedans. 2. carol (rôle qa_chat_wl) y poste "cat-secret". 3. bob (Member, rôle absent de la whitelist) : `GET /channels/<id>/messages` puis `POST`. - Attendu : 401 pour bob. Obtenu : 200 avec "cat-secret" et `POST` 201 (bob peut lire et écrire). Idem avec un channel non synchronisé (whitelist de channel vide = ouvert, normal). La sidebar de bob masque pourtant le channel (filtre front), donc l'UI donne une fausse impression de protection. - Cause probable : `Channel.IsWhitelisted` (`backend/API/Channels/Channel.cs`) lit `Category.RolesWhitelist`, mais les commandes/requêtes de messages font `.Include(c => c.Category)` sans `.ThenInclude(c => c.RolesWhitelist).ThenInclude(r => r.Role)` (ex. `Messages/List/ListMessagesQuery.cs:22`, `Create/CreateMessageCommand.cs`, `Update`, `Delete`, `Get`, `Ack`) : la collection est vide => `Count == 0` => accès autorisé. Les diffusions SignalR NewMessage/UpdateMessage/RemoveMessage (même filtre) sont donc envoyées aux non-autorisés. </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

label

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