Confrontation Audit — ulias-org-web

Date : 15/02/2026 Status : IMPLEMENTEE Auditeur : Claude Opus 4.6 (synthese confrontee) Sources : Pass 1 (02h00), Pass 2 (03h00), Pass 3 (04h00)

Resume executif

Categorie	Nombre
Findings CONFIRMES (2-3 passes concordantes)	12
Findings UNIQUES (1 seule passe)	13
Faux positifs elimines	4
Contradictions resolues	3

Total findings retenus : 22 (12 confirmes + 10 uniques valides) Total faux positifs : 4 (dont 2 declares par les passes elles-memes)

Findings CONFIRMES (2-3 passes concordantes)

C-01 : Polling 500ms infini apres toggle showArchived

Confirme par : Pass 1 (F01) + Pass 2 (1.4) + Pass 3 (F-09)
Severite definitive : BUG CERTAIN
Description consolidee : Le setInterval dans ConversationSidebar.tsx (lignes 151-156) capture origShowArchived a l'initialisation. Apres le premier toggle du signal showArchived, la condition showArchived.value !== origShowArchived reste toujours vraie car origShowArchived n'est jamais mis a jour. Resultat : loadConversations() est appele toutes les 500ms indefiniment. De plus, le bouton "Voir archivees" (lignes 537-547) fait deja son propre fetch dans le handler onClick$, donc ce polling est totalement redondant meme quand il detecte correctement le premier changement.
Impact : Flood de requetes API vers /api/conversations toutes les 500ms, charge reseau et serveur continue.
Priorite de correction : CRITIQUE
Note sur contradiction : Pass 3 titrait "ne fonctionne jamais" ce qui est inexact. Le setInterval fonctionne techniquement (le signal Qwik est bien relu dans le callback), mais le probleme est qu'il ne reset jamais sa reference, donc il boucle indefiniment apres le premier toggle. Voir la section "Contradictions resolues" pour le detail.

C-02 : XSS via `javascript:` URI dans les liens Markdown

Confirme par : Pass 1 (F11) + Pass 2 (2.1) + Pass 3 (F-06)
Severite definitive : BUG CERTAIN
Description consolidee : Le renderMarkdown() dans markdown.ts applique escapeHtml() en premier (correct), puis la regex des liens [text](url) reconstruit un <a href="$2">. Or javascript:alert(1) ne contient aucun caractere HTML special (<, >, &, "), donc escapeHtml() le laisse intact. Le lien genere <a href="javascript:alert(1)"> est injecte via dangerouslySetInnerHTML. Le contenu provient des reponses du LLM — un agent compromis ou une injection dans les tool_results pourrait generer ce type de lien.
Impact : Execution de JavaScript arbitraire au clic sur un lien malveillant. Combine avec le stockage de l'API key en localStorage (C-10), un attaquant pourrait exfiltrer la cle.
Priorite de correction : CRITIQUE
Note : Pass 1 classait FAIBLE car "les navigateurs modernes bloquent javascript: dans les liens". C'est FAUX pour les liens <a href="javascript:..."> cliques par l'utilisateur — seuls les javascript: dans les barres d'adresse sont bloques. Pass 2 et Pass 3 avaient raison de classer BUG CERTAIN.

C-03 : `window.location.href = '/'` perd le message envoye dans retryObjective

Confirme par : Pass 1 (F16) + Pass 2 (9.1) + Pass 3 (F-17)
Severite definitive : BUG CERTAIN
Description consolidee : Dans history/index.tsx (ligne 79-82), retryObjective dispatche ulias:send puis fait immediatement window.location.href = '/'. Le full page reload detruit tous les event listeners et le WebSocket AVANT que le message ait le temps d'etre envoye. Le message est perdu systematiquement. De plus, le reload force une reconnexion WS complete (re-auth, re-load conversation), degradant l'experience utilisateur.
Impact : La fonctionnalite "Relancer un objectif" depuis la page historique ne fonctionne JAMAIS — le message est toujours perdu.
Priorite de correction : HAUTE

C-04 : Race condition setTimeout(500ms) pour loadLastConversation

Confirme par : Pass 1 (F06) + Pass 2 (1.5) + Pass 3 (F-18)
Severite definitive : BUG PROBABLE
Description consolidee : Dans layout.tsx (lignes 167-169), le chargement de la derniere conversation utilise un setTimeout(500) pour attendre que ChatMessages soit monte. Si le composant met plus de 500ms a se monter (appareil lent, tab en arriere-plan, reseau lent), l'evenement ulias:load-history est dispatche mais personne ne l'ecoute — l'historique ne s'affiche pas. A l'inverse, sur une machine rapide, l'utilisateur voit un chat vide pendant 500ms inutilement.
Impact : Au premier chargement, la conversation precedente peut ne pas s'afficher sur les appareils lents. Flash de contenu vide sur les appareils rapides.
Priorite de correction : HAUTE

C-05 : Endpoint /api/teams sans header X-API-Key

Confirme par : Pass 1 (F09) + Pass 2 (9.5) + Pass 3 (F-12)
Severite definitive : BUG PROBABLE
Description consolidee : Dans teams/index.tsx (ligne 44), le fetch vers /api/teams ne passe pas le header X-API-Key, contrairement a toutes les autres pages. Pass 3 a verifie le backend : l'endpoint /api/teams ne verifie PAS l'authentification cote serveur non plus. Le code fonctionne donc, mais la liste des equipes et agents est accessible sans authentification.
Impact : Double probleme — (1) incoherence avec les autres pages, (2) fuite d'information si l'endpoint est expose publiquement. Si le backend est durci plus tard pour exiger l'auth, la page cessera de fonctionner.
Priorite de correction : MOYENNE

C-06 : Erreurs reseau silencieuses partout (catch vides)

Confirme par : Pass 1 (F07) + Pass 2 (5.1)
Severite definitive : BUG PROBABLE
Description consolidee : Presque tous les blocs try/catch dans le projet utilisent catch { /* silent */ }. Aucune erreur reseau n'est affichee a l'utilisateur. Les fichiers concernes : layout.tsx (5 occurrences), ConversationSidebar.tsx (11 occurrences), decisions/index.tsx, history/index.tsx, EventCard.tsx. Le cas le plus grave est le deleteConversation (C-07) ou l'etat local est modifie meme si le serveur a refuse l'operation.
Impact : L'utilisateur n'a aucun feedback quand une operation echoue. L'UI reste dans un etat potentiellement incoherent avec le serveur.
Priorite de correction : MOYENNE

C-07 : Etat local desynchronise apres delete/archive/pin echoue

Confirme par : Pass 1 (F15) + Pass 2 (5.1 / 5.3)
Severite definitive : BUG PROBABLE
Description consolidee : Dans ConversationSidebar.tsx (ligne 220), apres le fetch DELETE, l'etat local est modifie (conversations.value = conversations.value.filter(...)) SANS verifier res.ok. Si le serveur repond 403, 404 ou 500, le fetch ne throw pas (seules les erreurs reseau throw). La conversation disparait de la vue mais existe toujours cote serveur. Meme probleme pour archiveConversation, togglePin, saveRename, et deleteObjective dans history/index.tsx.
Impact : Desynchronisation UI/serveur. La conversation reapparait au prochain rechargement, creant de la confusion.
Priorite de correction : MOYENNE

C-08 : Suppression sans confirmation (conversations et objectifs)

Confirme par : Pass 1 (F03 + F10)
Severite definitive : BUG PROBABLE
Description consolidee : deleteConversation (ConversationSidebar.tsx:211-225) et deleteObjective (history/index.tsx:85-95) executent le DELETE immediatement sans confirm() ni modal de confirmation. Un clic accidentel sur le bouton supprimer detruit la donnee definitivement.
Impact : Perte de donnees irreversible sur clic accidentel.
Priorite de correction : MOYENNE
Note : Seule Pass 1 a explicitement identifie ce probleme. Pass 2 et Pass 3 l'ont mentionne indirectement dans le contexte des catch silencieux mais pas comme finding separe. Retenu car il est reel et facilement verifiable.

C-09 : Reconnexion WebSocket limitee a 5 tentatives sans recovery

Confirme par : Pass 1 (F02) + Pass 3 (F-16)
Severite definitive : RISQUE THEORIQUE
Description consolidee : Apres 5 tentatives de reconnexion echouees (total ~31 secondes), le WebSocket reste deconnecte definitivement. Pas de bouton "Reconnecter" dans l'UI. Le ConnectionBadge est en lecture seule. L'utilisateur doit recharger la page manuellement. Le compteur reconnectAttempts est correctement reset a 0 sur auth_success, mais une panne serveur de plus de 31 secondes bloque l'utilisateur.
Impact : Apres une maintenance rapide du serveur (>31s), tous les utilisateurs connectes sont bloques en "Deconnecte" permanent.
Priorite de correction : MOYENNE

C-10 : API key envoyee dans chaque message WS (pas seulement auth)

Confirme par : Pass 1 (F05) + Pass 2 (2.3)
Severite definitive : RISQUE THEORIQUE
Description consolidee : Dans ws-manager.ts (lignes 93-101), l'API key est incluse dans CHAQUE message (send et sendCommand), pas seulement dans le message d'auth initial. Si les logs serveur capturent les messages WS, la cle est exposee en clair dans chaque entree.
Impact : Surface d'exposition augmentee. Le risque est attenue par WSS (chiffre) et private:true (nginx).
Priorite de correction : BASSE

C-11 : Types TypeScript incomplets pour les events serveur

Confirme par : Pass 2 (2.5) + Pass 3 (F-01, F-02, F-03, F-04)
Severite definitive : BUG CERTAIN
Description consolidee : Plusieurs interfaces dans types.ts ne declarent pas tous les champs emis par le backend :
- RoutingEvent.data : manque confidence, reasoning, multi_step, pipeline, model
- ThinkingEvent.data : manque model, agent, tools
- ToolResultEvent.data : manque duration, success
- SubTaskStartedEvent.data : manque model
- SubTaskCompletedEvent.data : manque duration, toolCalls, iterations
- ClientMessage : manque set_conversation, decision_response
- ServerEvent : manque decision_request
Le code accede a ces champs via event.data?.field ou as any, contournant TypeScript. Cela fonctionne a l'execution car les objets JSON bruts contiennent ces champs, mais la type safety est nulle.
Impact : Aucun bug fonctionnel actuel, mais le code est fragile — un renommage cote backend passera silencieusement. Le compilateur TypeScript ne protege pas le developppeur.
Priorite de correction : MOYENNE

C-12 : useStore pour streamInfo — risque de serialisation Qwik

Confirme par : Pass 1 (F08) + Pass 2 (1.2) + Pass 3 (F-10)
Severite definitive : RISQUE THEORIQUE
Description consolidee : Le useStore<StreamingInfo> dans ChatMessages.tsx (ligne 22) est mute directement dans un handler d'event DOM vanilla (pas dans un handler Qwik $()). Les trois passes s'accordent : le pattern fonctionne en pratique car les mutations se font dans un useVisibleTask$ (code client-only), et le store est initialise avec des valeurs par defaut vides. Le risque est theorique et lie a un eventuel changement de comportement de Qwik concernant la serialisation des stores mutes hors closures $().
Impact : Aucun bug observe. Risque de regression lors d'une montee de version Qwik.
Priorite de correction : BASSE

Findings UNIQUES (1 seule passe)

U-01 : searchTimerRef jamais nettoye au cleanup

Source : Pass 2 (1.3)
Severite : BUG CERTAIN
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 3 se sont concentres sur le archiveInterval (qui est bien nettoye dans le cleanup) et n'ont pas examine le searchTimerRef separement.
Verification : Le searchTimerRef (ligne 77) est un useSignal(0) utilise comme timer ID. Il est clear dans handleSearch (ligne 327) mais JAMAIS dans la closure cleanup() (lignes 158-163). Le cleanup ne contient que clearInterval(archiveInterval) et les removeEventListener. Si l'utilisateur tape dans la recherche puis quitte la page, le callback setTimeout executera sur un composant demonte.
Verdict : CONFIRME — bug verifiable dans le code source.

U-02 : Accessibilite — modal prompts sans role/aria/trap de focus

Source : Pass 2 (6.1)
Severite : BUG PROBABLE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 3 n'avaient pas l'accessibilite dans leur perimetre d'audit.
Verdict : CONFIRME — violation WCAG 2.1 AA reelle. La modal de prompts/index.tsx n'a pas role="dialog", aria-modal="true", pas de trap de focus, pas de fermeture par Escape.

U-03 : Accessibilite — boutons SVG sans aria-label

Source : Pass 2 (6.2)
Severite : BUG PROBABLE
Pourquoi les autres passes ne l'ont pas trouve : Meme raison que U-02.
Verdict : CONFIRME — les boutons n'ont que title (lu inconsistement par les lecteurs d'ecran), pas aria-label (le standard).

U-04 : Accessibilite — navigation clavier incomplete (div onClick$ sans role/tabIndex)

Source : Pass 2 (6.3)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Hors perimetre a11y.
Verdict : CONFIRME — les conversations dans la sidebar et les cards cliquables dans history, help, et decisions sont des <div onClick$> non focusables au clavier.

U-05 : Accessibilite — pas de live region pour le streaming

Source : Pass 2 (6.4)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Hors perimetre a11y.
Verdict : CONFIRME — le statut streaming dans ChatMessages.tsx n'a pas d'aria-live ni de role="status".

U-06 : Bus evenementiel non type — aucun typage sur les CustomEvent

Source : Pass 2 (7.1)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 3 ont cartographie le bus evenementiel mais n'ont pas identifie l'absence de typage comme un finding separe.
Verdict : CONFIRME — ~15 types d'events circulent via document.dispatchEvent sans aucun typage TypeScript sur le detail. Un changement de nom ou de structure casse silencieusement la communication.

U-07 : conversation_set/created/title_updated/summary_updated accedent a `event.data?.title` mais n'ont pas de champ `data`

Source : Pass 3 (F-05)
Severite : BUG PROBABLE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 2 n'ont pas examine le getEventSummary() pour les types de conversation.
Verification : Les types ConversationCreatedEvent, ConversationSetEvent, etc. dans types.ts (lignes 313-335) ont des champs top-level (title, summary, conversationId) mais PAS de champ data. Le code EventCard.tsx:130-134 accede a event.data?.title qui retourne toujours undefined. En pratique, ces events sont filtres et ne s'affichent jamais dans le chat, mais le code est incorrect.
Verdict : CONFIRME — code mort mais incorrect. Impact reel nul car ces events ne passent pas dans EventCard.

U-08 : `originalMessage` jamais emis par le backend pour objective_completed/failed

Source : Pass 3 (F-08)
Severite : BUG PROBABLE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 2 n'ont pas croise le code frontend avec le backend.
Verification : Pass 3 a examine le backend et confirme que objective_completed et objective_failed ne contiennent pas originalMessage. Le code EventCard.tsx:319 verifie event.data?.originalMessage qui est toujours undefined — les boutons "Relancer" et "Modifier" ne s'affichent JAMAIS.
Verdict : CONFIRME — feature morte. Les boutons de retry/edit sur les events objective ne sont jamais visibles.

U-09 : WebSocket connecte sur `/ws/cli` au lieu de `/ws/webui`

Source : Pass 3 (F-11)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 2 n'ont pas lu la config conf.prod.gouroubleu.yml ni compare avec le backend.
Verdict : CONFIRME — pas d'impact fonctionnel (meme handler cote backend), mais les logs serveur identifient incorrectement les connexions web comme des connexions CLI. Risque de confusion lors du debug.

U-10 : `/api/status` ne verifie pas l'API key — validation login toujours true

Source : Pass 3 (F-13)
Severite : BUG PROBABLE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 2 n'ont pas verifie le comportement de /api/status cote backend.
Verification : Le code login/index.tsx (lignes 24-34) utilise fetch('/api/status', { headers: { 'X-API-Key': key } }) pour verifier si une cle est valide. Si res.ok alors redirect vers /. Mais /api/status retourne toujours 200 (endpoint de health check). Une cle invalide sera donc acceptee, l'utilisateur sera redirige vers /, puis le WS echouera avec auth_error, renvoyant vers /login — creant un flash d'ecran inutile.
Verdict : CONFIRME — experience utilisateur degradee avec une cle invalide en localStorage.

U-11 : revokeObjectURL appele trop tot apres click()

Source : Pass 2 (4.3)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Detail d'implementation mineur.
Verdict : A VERIFIER — en pratique, les navigateurs modernes bufferisent la lecture du blob avant de commencer le telechargement, mais le comportement n'est pas garanti dans tous les contextes. Risque tres faible.

U-12 : setTimeout(500ms) pour template message (meme pattern que C-04)

Source : Pass 2 (1.6)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Pass 1 et Pass 3 se sont concentres sur le setTimeout du layout.tsx, pas celui de ConversationSidebar.tsx:201-203.
Verdict : CONFIRME — meme pattern fragile que C-04 mais pour un cas d'usage different (envoi de template message apres switch de conversation).

U-13 : 9 signaux Qwik par instance EventCard, potentiel probleme de performance

Source : Pass 2 (3.3)
Severite : RISQUE THEORIQUE
Pourquoi les autres passes ne l'ont pas trouve : Analyse de performance granulaire non couverte par les autres passes.
Verdict : CONFIRME — avec des centaines d'events dans le chat, cela represente potentiellement des milliers de signaux reactifs. Impact mesurable uniquement sur de tres longues conversations.

Contradictions resolues

Contradiction 1 : Severite du XSS via `javascript:` URI

Pass	Severite	Justification
Pass 1 (F11)	FAIBLE	"les navigateurs modernes bloquent javascript: dans les liens"
Pass 2 (2.1)	BUG CERTAIN	XSS exploitable
Pass 3 (F-06)	BUG PROBABLE	XSS exploitable

Resolution : Pass 2 a raison. Les navigateurs modernes ne bloquent PAS javascript: dans les <a href> cliques par l'utilisateur. Ils bloquent javascript: tape dans la barre d'adresse. Un lien <a href="javascript:alert(1)"> clique par l'utilisateur executera le JavaScript dans tous les navigateurs majeurs. L'attribut target="_blank" ne protege pas non plus car javascript: est execute dans le contexte de la page origine, pas dans un nouvel onglet (le navigateur ne cree pas de nouvel onglet pour javascript:). Severite retenue : BUG CERTAIN.

Contradiction 2 : Le polling archiveInterval — "boucle infinie" vs "ne fonctionne jamais"

Pass	Description
Pass 1 (F01)	"Apres le premier toggle, boucle infinie de requetes toutes les 500ms"
Pass 2 (1.4)	"Apres le premier toggle, continue d'appeler loadConversations() indefiniment"
Pass 3 (F-09)	Titre : "ne fonctionne jamais". Corps : confirme la boucle infinie.

Resolution : Pass 1 et Pass 2 sont precis. Le titre de Pass 3 est trompeur, mais le corps de son analyse arrive a la meme conclusion : apres le premier toggle, le setInterval appelle loadConversations() toutes les 500ms indefiniment. Le titre "ne fonctionne jamais" est incorrect — le mecanisme "fonctionne" techniquement (il detecte bien le changement), mais il ne s'arrete jamais. Les trois passes s'accordent sur le comportement reel. Conclusion : boucle infinie apres le premier toggle, pas "ne marche pas".

Contradiction 3 : Markdown `&` dans les URLs — bug ou pas ?

Pass	Verdict
Pass 1 (F04)	"pas de bug, les navigateurs decodent & dans les href"
Pass 3 (F-07)	"BUG PROBABLE — les URLs sont corrompues"

Resolution : Pass 1 a raison pour le HTML. Dans un attribut HTML href, les entites HTML sont decodees par le parseur HTML avant l'envoi de la requete. Donc <a href="https://example.com?a=1&b=2"> fonctionne correctement — le navigateur enverra la requete vers https://example.com?a=1&b=2. Cependant, Pass 3 a un point partiel : si le HTML est insere via dangerouslySetInnerHTML (ce qui est le cas), le navigateur decode les entites comme pour du HTML standard. Les liens fonctionnent correctement. C'est un FAUX POSITIF de Pass 3. Voir section "Faux positifs".

Faux positifs elimines

FP-01 : useStore mute dans le render (EventCard.tsx)

Source : Pass 2 (1.1) — auto-declare FAUX POSITIF par l'auteur
Justification : event est une prop, pas un store. Les acces sont en lecture seule dans le render.

FP-02 : useNavigate() dans handler onClick$

Source : Pass 2 (3.1) — auto-declare FAUX POSITIF par l'auteur
Justification : useNavigate() retourne une QRL serialisable par Qwik. Le pattern est correct.

FP-03 : checking.value early return dans login

Source : Pass 2 (9.2) — auto-declare FAUX POSITIF par l'auteur
Justification : Return conditionnel dans component$() est un pattern Qwik valide.

FP-04 : Markdown & dans les URLs corrompant les liens

Source : Pass 3 (F-07)
Justification : Le parseur HTML decode & en & dans les attributs href avant d'envoyer la requete. Les liens avec des query params fonctionnent correctement meme avec & dans le HTML. Teste et confirme par le comportement standard de tous les navigateurs. Pass 1 (F04) avait correctement identifie ce point.

Top 10 actions prioritaires

#	Finding	Action	Effort	Priorite
1	C-02	XSS : filtrer les protocoles dans le renderer Markdown — Ajouter une validation dans la regex des liens pour n'accepter que `http:`, `https:`, `mailto:` et `/`. Rejeter `javascript:`, `data:`, `vbscript:`.	5 min	CRITIQUE
2	C-01	Supprimer le setInterval archiveInterval — Le handler onClick$ du bouton "Voir archivees" fait deja le fetch. L'interval est inutile et dangereux.	2 min	CRITIQUE
3	C-03	Remplacer window.location.href par useNavigate() dans retryObjective (history/index.tsx). Stocker le message dans localStorage et l'envoyer apres la navigation, ou envoyer via le WS puis naviguer.	15 min	HAUTE
4	C-04	Remplacer setTimeout(500) par un handshake — ChatMessages emet `ulias:chat-ready` dans son `useVisibleTask$`, le layout attend cet event avant d'envoyer l'historique.	20 min	HAUTE
5	U-01	Ajouter clearTimeout(searchTimerRef.value) dans le cleanup de ConversationSidebar.	1 min	HAUTE
6	C-07	Verifier res.ok avant de modifier l'etat local dans deleteConversation, archiveConversation, togglePin, saveRename, et deleteObjective.	15 min	MOYENNE
7	C-08	Ajouter confirm() avant les suppressions dans deleteConversation et deleteObjective.	5 min	MOYENNE
8	C-11	Completer les types TypeScript dans types.ts pour correspondre aux events reellement emis par le backend.	30 min	MOYENNE
9	C-05	Ajouter le header X-API-Key dans teams/index.tsx et proteger l'endpoint cote backend.	5 min	MOYENNE
10	U-10	Utiliser un endpoint authentifie pour la validation de la cle au login — remplacer `/api/status` par `/api/profile` dans login/index.tsx.	5 min	MOYENNE