senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/AUDIT_TECHNIQUE_INTEGRAL_2026_02.md
senke ae586f6134 Phase 2 stabilisation: code mort, Modal→Dialog, feature flags, tests, router split, Rust legacy 
Bloc A - Code mort:
- Suppression Studio (components, views, features)
- Suppression gamification + services mock (projectService, storageService, gamificationService)
- Mise à jour Sidebar, Navbar, locales

Bloc B - Frontend:
- Suppression modal.tsx deprecated, Modal.stories (doublon Dialog)
- Feature flags: PLAYLIST_SEARCH, PLAYLIST_RECOMMENDATIONS, ROLE_MANAGEMENT = true
- Suppression 19 tests orphelins, retrait exclusions vitest.config

Bloc C - Backend:
- Extraction routes_auth.go depuis router.go

Bloc D - Rust:
- Suppression security_legacy.rs (code mort, patterns déjà dans security/)
2026-02-14 17:23:32 +01:00

15 KiB
Raw Blame History

🔍 AUDIT TECHNIQUE INTÉGRAL — Monorepo Veza

Date : 14 février 2026
Mandant : Comité d'investissement
Périmètre : Monorepo complet (frontend, backend, services Rust, infra, CI/CD)

EXECUTIVE SUMMARY

Le monorepo Veza est une plateforme audio collaborative (streaming, chat, marketplace) avec une architecture multi-services (Go, Rust, React). L’audit révèle :

Critère Verdict
Lancement en production ⚠️ Possible avec corrections urgentes
Vente / acquisition ❌ Non recommandé sans remédiation
Maintenance ⚠️ Risques élevés (dette, tests fragiles)
Refactorisation ✅ Recommandée (phases 2–3)
Réécriture ❌ Non nécessaire

Points positifs :

  • Backend Go solide (auth, RBAC, ownership, CSRF, rate limiting)
  • Chat Server Rust compile et fonctionne
  • Stream Server Rust compile
  • Migrations DB structurées
  • CI/CD configuré (Go, Rust, frontend, E2E)

Points critiques :

  • Route interne /api/v1/internal/tracks/:id/stream-ready non authentifiée
  • Vulnérabilités npm (React Router XSS, Axios DoS, etc.)
  • Rate limiting désactivé en développement
  • Tests frontend : ~42 % d’échecs (selon règles utilisateur)
  • Features "Coming Soon" (Gear, Live, Education, Queue, Developer) sans backend

1️⃣ CARTOGRAPHIE GLOBALE

Stack

Couche Technologie Version
Frontend React + Vite + TypeScript React 18.2, Vite 7.1
Backend API Go + Gin Go 1.23, Gin 1.11
Chat Server Rust + Axum + WebSocket Axum 0.8, Tokio 1.35
Stream Server Rust + Axum + HLS Rust 2021
Base de données PostgreSQL 16-alpine
Cache Redis 7-alpine
Message broker RabbitMQ 3-management
Shared lib veza-common (Rust) 0.1.0

Organisation du repo

veza/
├── apps/web/              # Frontend React (source unique UI)
├── veza-backend-api/      # API Go principale
├── veza-chat-server/      # Chat WebSocket Rust
├── veza-stream-server/    # Streaming audio Rust
├── veza-common/            # Lib Rust partagée (logging, types)
├── veza-docs/              # Documentation
├── packages/               # (vide ou minimal)
├── config/                 # Docker, HAProxy
├── infra/                  # docker-compose lab
└── .github/workflows/      # CI/CD

Workspaces npm : apps/web, packages/* (package.json racine)

Flux fonctionnels

Frontend (React) ──► Backend API (Go) ──► PostgreSQL
       │                    │
       │                    ├──► Redis (sessions, CSRF, rate limit)
       │                    ├──► RabbitMQ (jobs)
       │                    ├──► Stream Server (callback stream-ready)
       │                    └──► Chat Server (JWT token)
       │
       ├──► Chat Server (WebSocket)
       └──► Stream Server (HLS/audio)

Dépendances critiques

  • Backend : GORM, JWT, bcrypt, ClamAV (go-clamd), AWS S3, Sentry, Prometheus
  • Frontend : React Query, Zustand, Axios, i18next, Framer Motion, HLS.js
  • Chat/Stream : SQLx, jsonwebtoken, Redis, RabbitMQ (lapin)

Dépendances obsolètes / abandonnées

  • veza-common : SQLx 0.8 (aligné avec chat/stream) — conflit historique résolu
  • Pas de dépendance abandonnée majeure identifiée

Technologies utilisées vs déclarées

Déclaré Réel
veza-desktop (Electron) Non présent dans workspaces npm
Nx / Turborepo / Lerna Aucun — monorepo npm basique
Design tokens Présents (apps/web/docs/DESIGN_TOKENS.md)

2️⃣ CE QUE LE PRODUIT PERMET RÉELLEMENT

Features validées (implémentées et utilisables)

Feature Backend Frontend Tests
Auth (login, register, 2FA) ✅ ✅ ✅
Sessions, logout, refresh ✅ ✅ ✅
Password reset ✅ ✅ ✅
Email verification ✅ ✅ ✅
OAuth (Google, GitHub, Discord) ✅ ✅ Partiel
Tracks (CRUD, upload, HLS) ✅ ✅ ✅
Playlists (CRUD, collaborateurs) ✅ ✅ ✅
Marketplace (products, cart, checkout) ✅ ✅ ✅
Wishlist, Purchases ✅ ✅ ✅
Chat (token, stats) ✅ ✅ ✅
Social (feed, posts, groups, follow) ✅ ✅ ✅
Webhooks ✅ ✅ ✅
Analytics ✅ ✅ ✅
Admin (audit, unlock, pprof) ✅ ✅ ✅
Roles, RBAC ✅ ✅ ✅
Notifications ✅ ✅ ✅
Data export (GDPR) ✅ ✅ -

Features incomplètes

Feature État
OAuth Config via env, baseURL hardcodé veza.fr si non défini
Stream Server callback Route interne non authentifiée
E2E Présents mais résultats instables (e2e-results.json)

Features fantômes / mortes

Feature Route État
Gear /gear ComingSoon placeholder
Live /live ComingSoon placeholder
Education /education ComingSoon placeholder
Queue /queue ComingSoon placeholder
Developer /developer ComingSoon placeholder

Incohérences produit / code

  • README mentionne veza-desktop (Electron) mais pas dans workspaces
  • docker-compose.prod.yml utilise HAProxy ; docker-compose.yml (dev) non
  • dist_verification committé (artefacts de build) — mauvaise pratique

3️⃣ VALIDATION FONCTIONNELLE

Tests

Composant Commande Résultat
Backend Go go test ./... -short Exécution longue (timeout 60s)
Chat Server cargo test ✅
Stream Server cargo check ✅ (warnings)
Frontend npm run test -- --run ~42 % échecs (règles utilisateur)
E2E npx playwright test Instable

Points de rupture

  1. Route interne stream-ready : Appelée par Stream Server sans auth — n’importe qui peut forger un callback.
  2. Rate limiting : Désactivé en dev (config.Env == config.EnvDevelopment) — risque en staging si APP_ENV mal configuré.
  3. CSRF : Désactivé si Redis indisponible (sauf prod où démarrage échoue).

Scénarios de crash évidents

  • Redis down en prod → crash (CSRF requis)
  • ClamAV down avec CLAMAV_REQUIRED=true → uploads rejetés
  • JWT_SECRET vide → crash au démarrage (correct)

Zones non testées

  • Handlers OAuth (flows complets)
  • Intégration Stream Server ↔ Backend
  • Webhooks sortants (workers)

4️⃣ AUDIT DE SÉCURITÉ — OWASP TOP 10

A01 – Broken Access Control

Point Gravité Détail
Route interne stream-ready Critique POST /api/v1/internal/tracks/:id/stream-ready sans auth. Exploitation : forger des callbacks pour modifier le statut de tracks.
Ownership ✅ RequireOwnershipOrAdmin sur users, tracks, playlists, products
Admin ✅ RequireAdmin sur /admin/*
Sessions ✅ Vérification ownership sur DELETE /sessions/:id (à confirmer dans handler)

Correctif A01 : Protéger la route interne par API key ou IP whitelist (réseau interne).

A02 – Cryptographic Failures

Point Gravité Détail
Mots de passe ✅ bcrypt (golang.org/x/crypto/bcrypt)
JWT ✅ HS256, validation stricte (alg, exp, iss, aud)
Secrets ⚠️ Moyenne JWT_SECRET requis en prod (:? dans docker-compose.prod.yml)
HTTPS ⚠️ COOKIE_SECURE=true en prod ; dépend du reverse proxy

Correctif A02 : S’assurer que TLS est forcé au niveau HAProxy/load balancer.

A03 – Injection

Point Gravité Détail
SQL ✅ GORM + prepared statements ; pas de concaténation
Full-text search ✅ plainto_tsquery avec paramètres
XSS ⚠️ Moyenne DOMPurify présent côté frontend ; pas de sanitization systématique côté backend pour tous les champs texte

Correctif A03 : Sanitiser les champs affichés (comments, posts, etc.) côté backend ou documenter la responsabilité frontend.

A04 – Insecure Design

Point Gravité Détail
Callback stream-ready Critique Pas d’authentification du callback Stream Server → Backend
Rate limiting dev ⚠️ Faible Désactivé en dev — acceptable si staging/prod corrects
Validation ✅ go-playground/validator, EmailValidator, PasswordValidator

Correctif A04 : Authentifier le callback (header X-Stream-Server-API-Key ou mTLS).

A05 – Security Misconfiguration

Point Gravité Détail
CORS ✅ Validation stricte en prod, pas de wildcard
Debug ✅ Stack traces uniquement en dev/DEBUG
Swagger ⚠️ Faible Exposé en prod — à restreindre ou désactiver
Secrets ✅ .env dans .gitignore ; SECRETS_VERIFICATION.md

Correctif A05 : Désactiver Swagger en prod ou le protéger par auth.

A06 – Vulnerable & Outdated Components

Point Gravité Détail
npm Élevée React Router XSS (GHSA-2w69-qvjg-hvjx), Axios DoS (GHSA-43fc-jf86-j433), cookie, diff, jose, lodash, node-forge
Go ✅ govulncheck dans CI
Rust ✅ cargo audit dans CI

Correctif A06 : npm audit fix ; mise à jour manuelle si breaking.

A07 – Identification & Authentication Failures

Point Gravité Détail
JWT ✅ Validation complète, token versioning
Sessions ✅ DB, expiration, révocation
Account lockout ✅ 5 tentatives, 30 min
Password reset ✅ Tokens avec expiration, audit

A08 – Software & Data Integrity Failures

Point Gravité Détail
CI/CD ⚠️ Moyenne Pas de signature des images Docker
Build ✅ Types générés depuis OpenAPI

A09 – Logging & Monitoring Failures

Point Gravité Détail
Logs ✅ Zap structuré, pas de secrets en clair
Métriques ✅ Prometheus
Audit ✅ AuditService, audit_logs

A10 – SSRF

Point Gravité Détail
Webhooks ⚠️ Faible Appels sortants vers URLs utilisateur — risque SSRF si URL non validée
OAuth ✅ URLs fixes (Google, GitHub, Discord)

5️⃣ DETTE TECHNIQUE

Dette critique (bloquante)

Élément Fichier / Zone
Route stream-ready non protégée router.go:622-625
Vulnérabilités npm high apps/web/package.json

Dette structurante

Élément Détail
fmt.Printf debug dans router router.go:110-121 (logs ClamAV)
Duplication setup routes Nombreux trackService, chunkService recréés
Conventions Pas de tooling monorepo (Nx/Turborepo)
Tests fragiles Frontend 42 % échecs

Dette cosmétique

Élément Détail
Warnings Stream Server dead_code, unused_comparisons
Fichiers dist_verification committés .gitignore à étendre
Commentaires FR/EN mélangés Cohérence

6️⃣ QUALITÉ ARCHITECTURALE

Scores (sur 10)

Critère Score Justification
Architecture 7/10 Séparation claire (handlers, services, core) ; duplication de setup dans router
Maintenabilité 6/10 Code structuré ; dette, tests fragiles, pas de tooling monorepo
Sécurité 6/10 Bonnes bases (auth, RBAC, CSRF) ; faille callback, vulnérabilités npm
Scalabilité 7/10 Stateless API, Redis, RabbitMQ ; pas de stratégie cache avancée documentée

7️⃣ INFRA & DEVOPS

Docker

  • docker-compose.yml : dev (postgres, redis, rabbitmq, backend-api)
  • docker-compose.prod.yml : prod (postgres, redis, rabbitmq, backend, chat, stream, web, HAProxy)
  • Secrets : DB_PASS, RABBITMQ_PASS, JWT_SECRET requis en prod (:?)

Config

  • Variables d’environnement documentées (règles utilisateur)
  • Pas de secrets en clair dans les fichiers versionnés (vérification SECRETS_VERIFICATION.md)

Scripts

  • make utilisé (smoke, e2e, postman, etc.)
  • Pas de script dangereux identifié

8️⃣ RISQUES BUSINESS

CTO

  • Lancement prod : Possible après correction de la route stream-ready et des vulnérabilités npm.
  • Maintenance : Risque moyen : dette, tests instables, dépendances à mettre à jour.

Investisseur

  • Vente : Non recommandée sans remédiation des vulnérabilités et de la dette critique.
  • Valeur : Architecture solide, fonctionnalités riches ; qualité à renforcer.

Acquéreur

  • Refactorisation : Oui, phases 2–3 du plan d’action.
  • Réécriture : Non nécessaire.

9️⃣ PLAN D’ACTION PRIORISÉ

Phase 1 — Urgent (sécurité & stabilité)

Action Effort Fichiers
Protéger route /api/v1/internal/tracks/:id/stream-ready (API key ou IP) S router.go, middleware/
Corriger vulnérabilités npm (audit fix, mise à jour manuelle) S apps/web/package.json
Supprimer fmt.Printf debug du router S router.go
Étendre .gitignore pour dist_verification S .gitignore

Phase 2 — Stabilisation

Action Effort Détail
Stabiliser tests frontend M Analyser échecs, mocks, dépendances
Stabiliser E2E Playwright M Fiabiliser setup, timeouts
Documenter/sécuriser callback Stream Server S Spec API key, implémentation
Désactiver ou protéger Swagger en prod S Config conditionnelle

Phase 3 — Amélioration & refonte

Action Effort Détail
Introduire tooling monorepo (Turborepo/Nx) L Cache builds, orchestration
Réduire duplication dans router M Factoring des services
Corriger warnings Stream Server S dead_code, unused
Implémenter ou retirer features Coming Soon M Gear, Live, Education, Queue, Developer

CONCLUSION STRATÉGIQUE

Le monorepo Veza est techniquement viable avec une base solide (auth, RBAC, marketplace, chat, streaming). Les correctifs de la Phase 1 sont indispensables avant toute mise en production. La Phase 2 renforce la confiance (tests, documentation). La Phase 3 améliore la maintenabilité et la scalabilité.

Recommandation : Exécuter la Phase 1 sous 1–2 semaines, puis planifier la Phase 2 en parallèle du déploiement.

Rapport généré par audit technique automatisé — 14 février 2026