veza/docs/archive/frontend-sessions-2026/AUDIT_PRODUCTION_FRONTEND.md
senke 0e7097ed1b chore(cleanup): J1 — purge 220MB debris, archive session docs (complete)
First-attempt commit 3a5c6e184 only captured the .gitignore change; the
pre-commit hook silently dropped the 343 staged moves/deletes during
lint-staged's "no matching task" path. This commit re-applies the intended
J1 content on top of bec75f143 (which was pushed in parallel).

Uses --no-verify because:
- J1 only touches .md/.json/.log/.png/binaries — zero code that would
  benefit from lint-staged, typecheck, or vitest
- The hook demonstrated it corrupts pure-rename commits in this repo
- Explicitly authorized by user for this one commit

Changes (343 total: 169 deletions + 174 renames):

Binaries purged (~167 MB):
- veza-backend-api/{server,modern-server,encrypt_oauth_tokens,seed,seed-v2}

Generated reports purged:
- 9 apps/web/lint_report*.json (~32 MB)
- 8 apps/web/tsc_*.{log,txt} + ts_*.log (TS error snapshots)
- 3 apps/web/storybook_*.json (1375+ stored errors)
- apps/web/{build_errors*,build_output,final_errors}.txt
- 70 veza-backend-api/coverage*.out + coverage_groups/ (~4 MB)
- 3 veza-backend-api/internal/handlers/*.bak

Root cleanup:
- 54 audit-*.png (visual regression baselines, ~11 MB)
- 9 stale MVP-era scripts (Jan 27, hardcoded v0.101):
  start_{iteration,mvp,recovery}.sh,
  test_{mvp_endpoints,protected_endpoints,user_journey}.sh,
  validate_v0101.sh, verify_logs_setup.sh, gen_hash.py

Session docs archived (not deleted — preserved under docs/archive/):
- 78 apps/web/*.md     → docs/archive/frontend-sessions-2026/
- 43 veza-backend-api/*.md → docs/archive/backend-sessions-2026/
- 53 docs/{RETROSPECTIVE_V,SMOKE_TEST_V,PLAN_V0_,V0_*_RELEASE_SCOPE,
          AUDIT_,PLAN_ACTION_AUDIT,REMEDIATION_PROGRESS}*.md
                        → docs/archive/v0-history/

README.md and CONTRIBUTING.md preserved in apps/web/ and veza-backend-api/.

Note: The .gitignore rules preventing recurrence were already pushed in
3a5c6e184 and remain in place — this commit does not modify .gitignore.

Refs: AUDIT_REPORT.md §11
2026-04-14 17:12:03 +02:00

4.4 KiB

🔍 Audit de Production - Frontend Veza

Date : 2025-01-27
Cible : apps/web (Frontend React/Vite/TypeScript)
Objectif : Identification des bloquants pour un déploiement en production stable et sécurisé


📊 Résumé Exécutif

Score Global : 62/100 ⚠️

Verdict : NON PRÊT POUR LA PRODUCTION

Le frontend présente plusieurs problèmes critiques de sécurité et de qualité qui doivent être résolus avant tout déploiement en production.

Points Forts

  1. Architecture : Routes protégées correctement implémentées avec ProtectedRoute
  2. TypeScript : Configuration TypeScript présente et fonctionnelle
  3. Build : Configuration Vite optimisée avec chunk splitting et sourcemaps
  4. Tests : Infrastructure de tests présente (Vitest + Playwright)

Points Faibles Majeurs 🔴

  1. Sécurité Critique :

    • CSP avec unsafe-inline et unsafe-eval (CRITICAL)
    • Tokens JWT stockés dans localStorage (vulnérable au XSS)
    • Utilisation de dangerouslySetInnerHTML sans sanitisation complète
  2. Qualité du Code :

    • 122+ console.log/error/warn qui pollueront les logs de production
    • 480+ utilisations de any (perte de sécurité de type)
    • Hardcoding de localhost/127.0.0.1 dans plusieurs fichiers
  3. Gestion d'Erreur :

    • Nombreux catch qui loggent uniquement sans informer l'utilisateur
    • Erreurs API silencieuses dans certains composants
  4. Dette Technique :

    • 11 TODO/FIXME/HACK identifiés
    • Code temporaire (console.log avec commentaire "Temporary")

📋 Détail des Problèmes par Catégorie

🔴 CRITICAL (Bloquant Production)

  1. CSP avec unsafe-inline/unsafe-eval (vite.config.ts:64)

    • Impact : Vulnérabilité XSS, injection de scripts
    • Fix : Utiliser des nonces CSP stricts, supprimer unsafe-eval
  2. Tokens dans localStorage (Multiple fichiers)

    • Impact : Vol de tokens via XSS
    • Fix : Migrer vers httpOnly cookies ou sessionStorage avec rotation

🟠 HIGH (Risque Sécurité/Stabilité)

  1. dangerouslySetInnerHTML sans sanitisation complète (2 occurrences)

    • Impact : Risque XSS si sanitisation échoue
    • Fix : Vérifier sanitizeChatMessage, considérer une alternative
  2. Gestion d'erreur silencieuse (Multiple fichiers)

    • Impact : UX dégradée, bugs non visibles
    • Fix : Afficher des toasts/notifications pour toutes les erreurs utilisateur
  3. Hardcoding localhost (Multiple fichiers)

    • Impact : Build de production avec URLs de dev
    • Fix : Utiliser uniquement import.meta.env avec fallbacks appropriés

🟡 MEDIUM (Qualité/Performance)

  1. 480+ utilisations de any

    • Impact : Perte de sécurité de type, bugs potentiels
    • Fix : Typage progressif, interfaces strictes
  2. 122+ console.log/error/warn

    • Impact : Pollution des logs de production, fuite d'informations
    • Fix : Utiliser un logger conditionnel basé sur import.meta.env.DEV
  3. 11 TODO/FIXME/HACK

    • Impact : Dette technique, fonctionnalités incomplètes
    • Fix : Prioriser et résoudre ou documenter

🟢 LOW (Cosmétique/Maintenance)

  1. Code temporaire (LibraryManager.tsx:112)

    • Impact : Code mort, confusion
    • Fix : Supprimer ou implémenter la fonctionnalité
  2. Tests manquants (Plusieurs composants)

    • Impact : Risque de régression
    • Fix : Augmenter la couverture de tests

🎯 Plan d'Action Recommandé

Phase 1 : Sécurité Critique (1-2 jours)

  • Corriger CSP (supprimer unsafe-inline/unsafe-eval)
  • Migrer tokens vers httpOnly cookies
  • Audit complet de dangerouslySetInnerHTML

Phase 2 : Qualité Code (2-3 jours)

  • Remplacer tous les console.* par un logger conditionnel
  • Corriger hardcoding localhost
  • Améliorer gestion d'erreur (toasts partout)

Phase 3 : Dette Technique (1-2 jours)

  • Résoudre/prioriser les TODO
  • Réduire les any (typage progressif)
  • Nettoyer le code temporaire

📈 Métriques

  • Fichiers analysés : ~363 fichiers
  • Problèmes identifiés : 50+ (voir JSON détaillé)
  • Bloquants production : 2 (CRITICAL)
  • Risques sécurité : 3 (HIGH)
  • Problèmes qualité : 8 (MEDIUM)
  • Améliorations : 10+ (LOW)

Prochaine étape : Consulter le JSON détaillé (AUDIT_ISSUES.json) pour la liste complète des problèmes avec localisation exacte.