[Mineur] Avatar sans validation du contenu ni de la taille #124

New issue

Closed

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

asventi commented

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

Owner

Gravité : Mineur
Rapports QA d'origine : PROFILE-08

Texte, HTML, fichier vide déclarés image/png et 17 Mo acceptés ; l'image cassée n'a pas de repli.

Détails des rapports

[PROFILE-08] Avatar : aucune validation du contenu ni de la taille (fichier texte/HTML/vide « image/png », 17 Mo acceptés) — Gravité : Mineur

Où : PATCH /api/me/avatar
Étapes : upload multipart file avec : (a) texte brut nommé fake.png, content-type image/png ; (b) HTML avec content-type image/png ; (c) fichier vide ; (d) PNG aléatoire de 17 Mo ; (e) SVG contenant <script> en image/svg+xml.
Attendu : refus des non-images/fichiers vides et d'une taille > limite (10 Mo annoncé dans le brief) ; SVG refusé ou assaini.
Obtenu : 200 pour (a)-(e). Seul un content-type ne commençant pas par "image" (ex. text/plain) est refusé (422 INVALID_AVATAR_TYPE). Avatar cassé (image illisible) dans l'UI. Pas d'exécution de script pour le SVG : le téléchargement est servi en Content-Disposition: attachment et uniquement via <img> (pas de XSS constaté), mais pas de X-Content-Type-Options: nosniff.
Via l'UI : le Dropzone limite à 29 Mo (files/components/UploadDropzone.tsx:11, message "File too large, 29.0 MB maximum" OK), mais accepte un faux fake.png (texte) : l'avatar devient une image cassée affichée partout (sidebar, popup, Members) SANS repli sur le blobatar (ProfilePic.tsx:538-543, pas de onError). Côté API, > ~28,6 Mo -> 413 propre. Cache : chaque upload crée une nouvelle clé et l'ancienne est supprimée (404) : pas de souci de cache ; suppression d'avatar OK (retour au blobatar). Formats png/jpg/gif/webp OK.
Cause probable : backend/API/Users/Me/Patch/PatchProfilePictureCommand.cs:15 (ContentType.StartsWith("image") côté client).

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 :** PROFILE-08 Texte, HTML, fichier vide déclarés image/png et 17 Mo acceptés ; l'image cassée n'a pas de repli. ## Détails des rapports <details><summary>[PROFILE-08] Avatar : aucune validation du contenu ni de la taille (fichier texte/HTML/vide « image/png », 17 Mo acceptés) — Gravité : Mineur</summary> - Où : `PATCH /api/me/avatar` - Étapes : upload multipart `file` avec : (a) texte brut nommé fake.png, content-type image/png ; (b) HTML avec content-type image/png ; (c) fichier vide ; (d) PNG aléatoire de 17 Mo ; (e) SVG contenant `<script>` en `image/svg+xml`. - Attendu : refus des non-images/fichiers vides et d'une taille > limite (10 Mo annoncé dans le brief) ; SVG refusé ou assaini. - Obtenu : 200 pour (a)-(e). Seul un content-type ne commençant pas par "image" (ex. text/plain) est refusé (422 `INVALID_AVATAR_TYPE`). Avatar cassé (image illisible) dans l'UI. Pas d'exécution de script pour le SVG : le téléchargement est servi en `Content-Disposition: attachment` et uniquement via `<img>` (pas de XSS constaté), mais pas de `X-Content-Type-Options: nosniff`. - Via l'UI : le Dropzone limite à 29 Mo (`files/components/UploadDropzone.tsx:11`, message "File too large, 29.0 MB maximum" OK), mais accepte un faux `fake.png` (texte) : l'avatar devient une image cassée affichée partout (sidebar, popup, Members) SANS repli sur le blobatar (`ProfilePic.tsx:538-543`, pas de `onError`). Côté API, > ~28,6 Mo -> 413 propre. Cache : chaque upload crée une nouvelle clé et l'ancienne est supprimée (404) : pas de souci de cache ; suppression d'avatar OK (retour au blobatar). Formats png/jpg/gif/webp OK. - Cause probable : `backend/API/Users/Me/Patch/PatchProfilePictureCommand.cs:15` (`ContentType.StartsWith("image")` côté client). </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:17 +00:00

asventi self-assigned this

2026-10-28 10:54:45 +00:00

asventi started working

2026-10-28 11:10:47 +00:00

asventi stopped working

2026-10-28 12:42:55 +00:00

1 hour 32 minutes

asventi referenced this issue from a commit