senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/archive/root-md/AUDIT_TECHNIQUE_INTEGRAL_2026_02.md

423 lines
15 KiB
Markdown
Raw Normal View History

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 16:23:32 +00:00
# 🔍 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*
Reference in a new issue Copy permalink