[Majeur] Aucune limitation de débit ni verrouillage sur /auth/login et /auth/register #102

New issue

Closed

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

asventi commented

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

Owner

Gravité : Majeur
Rapports QA d'origine : AUTH-19, SECURITY_UX-24

28 tentatives de login en 4 s sans blocage : brute force possible.

Détails des rapports

[AUTH-19] Aucune protection contre le brute force sur `POST /auth/login` (ni rate limit, ni verrouillage) — Gravité : Majeur

Où : POST /api/auth/login
Étapes : 28 tentatives avec un mauvais mot de passe sur le même user qa en 4,4 s, puis le bon mot de passe.
Attendu : 429 / délai croissant / verrouillage temporaire après N échecs.
Obtenu : 28 x 406, aucun en-tête Retry-After/RateLimit, puis le bon mot de passe -> 200. Le rate limiter n'existe que pour le chatbot (AiBackendBuilder.cs, .RequireRateLimiting("ai-chat")) ; app.UseRateLimiter() (Program.cs:69) n'a aucune politique pour /auth.
Remarque : le mot de passe est aussi sans longueur max au login (100 000 caractères -> hash complet, 406) : charge CPU gratuite.

[SECURITY_UX-24] Aucune limitation de débit ni verrouillage sur `/auth/login` (et `/auth/register`) — Gravité : Mineur

Où : POST /api/auth/login
Étapes : 1. 30 tentatives avec un mauvais mot de passe sur un user qa. 2. Tentative avec le bon mot de passe.
Attendu : 429 / délai croissant après quelques échecs.
Obtenu : 30 × 406 (aucun ralentissement), puis 200 avec le bon mot de passe : brute-force possible. Seul ai-chat a un rate limiter (backend/API/AiBackend/AiBackendBuilder.cs:24). (Au passage : identifiants invalides = 406 au lieu de 401.)

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é :** Majeur **Rapports QA d'origine :** AUTH-19, SECURITY_UX-24 28 tentatives de login en 4 s sans blocage : brute force possible. ## Détails des rapports <details><summary>[AUTH-19] Aucune protection contre le brute force sur `POST /auth/login` (ni rate limit, ni verrouillage) — Gravité : Majeur</summary> - Où : `POST /api/auth/login` - Étapes : 28 tentatives avec un mauvais mot de passe sur le même user qa en 4,4 s, puis le bon mot de passe. - Attendu : 429 / délai croissant / verrouillage temporaire après N échecs. - Obtenu : 28 x `406`, aucun en-tête `Retry-After`/`RateLimit`, puis le bon mot de passe -> `200`. Le rate limiter n'existe que pour le chatbot (`AiBackendBuilder.cs`, `.RequireRateLimiting("ai-chat")`) ; `app.UseRateLimiter()` (`Program.cs:69`) n'a aucune politique pour `/auth`. - Remarque : le mot de passe est aussi sans longueur max au login (100 000 caractères -> hash complet, 406) : charge CPU gratuite. </details> <details><summary>[SECURITY_UX-24] Aucune limitation de débit ni verrouillage sur `/auth/login` (et `/auth/register`) — Gravité : Mineur</summary> - Où : `POST /api/auth/login` - Étapes : 1. 30 tentatives avec un mauvais mot de passe sur un user qa. 2. Tentative avec le bon mot de passe. - Attendu : 429 / délai croissant après quelques échecs. - Obtenu : 30 × 406 (aucun ralentissement), puis 200 avec le bon mot de passe : brute-force possible. Seul `ai-chat` a un rate limiter (`backend/API/AiBackend/AiBackendBuilder.cs:24`). (Au passage : identifiants invalides = 406 au lieu de 401.) </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:19 +00:00