senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/veza-backend-api/AUDIT_MODULE_VEZA_BACKEND_API.md
senke 2dfde29f7d refonte: backend-api go first; phase 1
2025-12-12 21:34:34 -05:00

55 KiB
Raw Blame History

AUDIT TECHNIQUE EXHAUSTIF - VEZA BACKEND API

Date: 2025-01-27
Auditeur: AI Assistant (Auto)
Module: veza-backend-api (Backend Go)
Version: 1.2.0
Méthodologie: Audit statique exhaustif + Analyse code + Tests + Configuration
Priorité: Production-ready audit

📋 TABLE DES MATIÈRES

  1. PHASE A - Cartographie du Module
  2. PHASE B - Santé Technique
  3. PHASE C - Sécurité
  4. PHASE D - Robustesse & Observabilité
  5. PHASE E - Performance & Scalabilité
  6. PHASE F - Liste Exhaustive des Problèmes Priorisés
  7. PHASE G - Plan d'Exécution

PHASE A - CARTOGRAPHIE DU MODULE

A.1 But du Module

Veza Backend API est le serveur API REST principal de la plateforme Veza, une plateforme audio collaborative. Il fournit :

  • Authentification & Autorisation : JWT (HS256), sessions DB, RBAC, OAuth partiel, 2FA (TOTP)
  • Gestion Utilisateurs : Profils, permissions, rôles, token versioning pour révocation
  • Gestion Contenu : Tracks (audio), playlists, marketplace (products, orders)
  • Chat & Collaboration : Rooms, messages, conversations (intégration Chat Server Rust)
  • Streaming : Intégration avec Stream Server (WebRTC) pour streaming audio
  • Audit & Monitoring : Logs structurés (zap), métriques Prometheus, Sentry error tracking
  • Jobs & Workers : Job queue (RabbitMQ), workers (email, thumbnails, analytics, webhooks)

Rôle dans l'écosystème Veza :

  • Backend Go : API REST principale (port 8080) - MODULE COURANT
  • Chat Server Rust : WebSocket chat (port 8081) - consommateur de tokens JWT via /api/v1/chat/token
  • Stream Server Rust : Streaming audio WebRTC (port 8082) - consommateur de tokens JWT
  • Frontend React : Consommateur de l'API REST

A.2 Entrées / Sorties

APIs Exposées

Base URL: http://localhost:8080 (configurable via APP_PORT, défaut: 8080)

Routes Principales (/api/v1/):

/api/v1/
├── /auth/*
│   ├── POST   /register              # Inscription
│   ├── POST   /login                  # Connexion (rate limited)
│   ├── POST   /refresh                # Renouvellement token
│   ├── POST   /verify-email           # Vérification email
│   ├── POST   /resend-verification   # Renvoyer vérification
│   ├── GET    /check-username         # Vérifier disponibilité username
│   ├── POST   /password/reset-request # Demande reset password
│   ├── POST   /password/reset         # Reset password
│   ├── POST   /logout                 # Déconnexion (protégé)
│   └── GET    /me                     # Profil utilisateur (protégé)
├── /users/*
│   ├── GET    /:id                    # Profil utilisateur
│   ├── GET    /by-username/:username # Profil par username
│   ├── PUT    /:id                    # Mise à jour profil (protégé)
│   └── GET    /:id/completion         # Complétion profil (protégé)
├── /tracks/*
│   ├── GET    /                       # Liste tracks
│   ├── GET    /:id                    # Détails track
│   ├── GET    /:id/stats              # Statistiques track
│   ├── GET    /:id/history            # Historique track
│   ├── GET    /:id/download           # Téléchargement track
│   ├── GET    /shared/:token          # Track partagé (public)
│   ├── POST   /                       # Upload track (protégé, creator role)
│   ├── PUT    /:id                    # Mise à jour track (protégé)
│   ├── DELETE /:id                    # Suppression track (protégé)
│   ├── POST   /:id/like               # Like track (protégé)
│   ├── DELETE /:id/like               # Unlike track (protégé)
│   ├── GET    /:id/likes              # Liste likes (protégé)
│   ├── POST   /:id/share              # Partager track (protégé)
│   └── DELETE /share/:id              # Révoquer partage (protégé)
├── /playlists/*                       # Gestion playlists (protégé)
├── /chat/*
│   └── POST   /token                  # Génération token WS (protégé)
├── /marketplace/*
│   ├── GET    /products               # Liste produits
│   ├── POST   /products               # Créer produit (protégé, creator role)
│   ├── POST   /orders                 # Créer commande (protégé)
│   └── GET    /download/:product_id   # URL téléchargement (protégé)
├── /sessions/*                        # Gestion sessions (protégé)
├── /uploads/*                         # Upload fichiers (protégé, rate limited)
├── /audit/*                           # Audit logs (protégé)
├── /conversations/*                   # Chat rooms (protégé)
├── /webhooks/*                        # Webhooks (protégé)
├── /admin/*                           # Routes admin (protégé, admin role)
├── /health                            # Health check simple
├── /healthz                           # Liveness probe
├── /readyz                            # Readiness probe
├── /status                            # Status complet (DB, Redis, Chat, Stream)
└── /metrics                           # Prometheus metrics

Formats:

  • Request/Response: JSON (application/json)
  • Auth: JWT Bearer tokens (Authorization: Bearer <token>)
  • Content-Type: application/json
  • File Upload: multipart/form-data (tracks, thumbnails)
  • WebSocket: Chat Server (Rust) - tokens JWT fournis par /api/v1/chat/token

Schémas JSON Principaux

User:

{
  "id": "uuid",
  "username": "string",
  "email": "string",
  "role": "user|admin|creator|premium|artist|producer|label",
  "token_version": 1,
  "created_at": "2025-01-27T10:00:00Z",
  "updated_at": "2025-01-27T10:00:00Z"
}

Track:

{
  "id": "uuid",
  "user_id": "uuid",
  "title": "string",
  "artist": "string",
  "duration": 180.5,
  "file_path": "string",
  "status": "processing|ready|error"
}

Error Response (standardisé):

{
  "success": false,
  "data": null,
  "error": {
    "code": 2001,
    "message": "Validation failed",
    "details": [
      {"field": "email", "message": "Invalid email format"}
    ],
    "request_id": "uuid",
    "timestamp": "2025-01-27T10:00:00Z"
  }
}

A.3 Dépendances Internes

Structure du Module:

veza-backend-api/
├── cmd/
│   ├── api/main.go                  # Point d'entrée principal (legacy?)
│   └── modern-server/main.go        # Point d'entrée moderne (ACTIF)
├── internal/
│   ├── api/                         # Routes et handlers HTTP
│   │   ├── router.go                # Configuration routes (APIRouter)
│   │   └── [user|track|chat|...]/  # Routes par domaine
│   ├── config/                      # Configuration centralisée
│   │   ├── config.go                # Config struct + NewConfig()
│   │   ├── env_loader.go            # Chargement .env
│   │   └── validator.go             # Validation config
│   ├── database/                    # Gestion DB
│   │   ├── database.go              # Connexion + migrations
│   │   └── migrations.go            # Migrations GORM (indexes)
│   ├── handlers/                    # Handlers HTTP (legacy + modern)
│   ├── middleware/                  # Middlewares Gin
│   │   ├── auth.go                  # AuthMiddleware (JWT + sessions)
│   │   ├── rbac_middleware.go       # RBAC permissions
│   │   ├── rate_limiter.go           # Rate limiting (Redis)
│   │   ├── error_handler.go         # Error handling standardisé
│   │   └── timeout.go               # Timeout middleware
│   ├── services/                    # Business logic
│   │   ├── jwt_service.go           # JWT generation/validation
│   │   ├── session_service.go       # Sessions DB
│   │   ├── user_service.go          # User management
│   │   └── [auth|track|playlist|...]/ # Services par domaine
│   ├── models/                      # Modèles GORM
│   ├── repositories/                # Data access layer
│   ├── workers/                     # Background workers
│   │   ├── job_worker.go            # Job queue worker
│   │   ├── email_job.go             # Email worker
│   │   └── [analytics|thumbnail|webhook]/ # Autres workers
│   ├── errors/                      # Error handling
│   ├── metrics/                     # Prometheus metrics
│   └── logging/                      # Logging (zap)
├── migrations/                      # Migrations SQL (100% SQL strategy)
│   ├── 001_extensions_and_types.sql
│   ├── 010_auth_and_users.sql
│   └── [020-900]_*.sql
└── tests/                           # Tests d'intégration

Packages Partagés:

  • internal/common/ : Types communs, validation
  • internal/types/ : Types métier (auth, user, stats)
  • internal/interfaces/ : Interfaces pour découplage

A.4 Dépendances Externes

Base de Données:

  • PostgreSQL (principal) : Via github.com/lib/pq + GORM (gorm.io/driver/postgres)
  • SQLite (tests uniquement) : Via gorm.io/driver/sqlite
  • Stratégie Migrations : 100% SQL (fichiers .sql dans migrations/), GORM uniquement pour indexes additionnels

Cache & Sessions:

  • Redis (github.com/redis/go-redis/v9) : Cache, rate limiting, sessions (optionnel via REDIS_ENABLE)

Message Queue:

  • RabbitMQ (github.com/rabbitmq/amqp091-go) : Job queue, event bus (optionnel via RABBITMQ_ENABLE)

HTTP Framework:

  • Gin (github.com/gin-gonic/gin) : Router HTTP

Auth & Security:

  • JWT (github.com/golang-jwt/jwt/v5) : Tokens JWT (HS256)
  • OTP (github.com/pquerna/otp) : 2FA TOTP
  • Crypto (golang.org/x/crypto) : Hashing passwords (bcrypt)

Monitoring & Observability:

  • Prometheus (github.com/prometheus/client_golang) : Métriques
  • Sentry (github.com/getsentry/sentry-go) : Error tracking
  • Zap (go.uber.org/zap) : Logging structuré

Validation:

  • Validator (github.com/go-playground/validator/v10) : Validation struct tags

Autres:

  • UUID (github.com/google/uuid) : Génération UUID
  • OAuth2 (golang.org/x/oauth2) : OAuth (partiel)
  • Rate Limiting (golang.org/x/time) : Rate limiting

A.5 Exécution

Commandes Build/Run/Dev

Build:

make build                    # Compile (bin/veza-backend-api)
make build-linux              # Compile pour Linux

Run:

make run                      # Build + run
make dev                      # Run en mode dev (go run)
make run-lab                  # Run en mode lab (dégradé sans Redis/RabbitMQ)

Tests:

make test                     # Tests unitaires
make test-coverage            # Tests avec couverture
make test-race                # Tests avec détection race conditions
make test-integration         # Tests d'intégration (nécessite Redis)

Qualité:

make lint                     # golangci-lint
make vet                      # go vet
make format                   # go fmt + goimports
make security                 # gosec + govulncheck

Migrations:

make migrate                  # Exécute migrations
make migrate-lab              # Migrations en environnement lab

Configuration

Variables d'Environnement Requises:

# REQUIS
JWT_SECRET=<32+ chars>        # Secret JWT (minimum 32 caractères)
DATABASE_URL=postgres://...   # URL PostgreSQL

# OPTIONNEL (avec defaults)
APP_PORT=8080                 # Port serveur HTTP
APP_ENV=development|test|staging|production
REDIS_URL=redis://localhost:6379
REDIS_ENABLE=true
RABBITMQ_URL=amqp://guest:guest@localhost:5672/
RABBITMQ_ENABLE=true
CORS_ALLOWED_ORIGINS=http://localhost:3000,http://localhost:5173
LOG_LEVEL=INFO|DEBUG|WARN|ERROR
HANDLER_TIMEOUT=30s
RATE_LIMIT_LIMIT=100
RATE_LIMIT_WINDOW=60
AUTH_RATE_LIMIT_LOGIN_ATTEMPTS=5
AUTH_RATE_LIMIT_LOGIN_WINDOW=1

Fichiers de Configuration:

  • .env : Variables d'environnement (chargé automatiquement)
  • .env.{env} : Variables par environnement (ex: .env.production)
  • Priorité : Variables système > .env.{env} > .env

Secrets Management:

  • Secrets dans variables d'environnement (pas de fichiers secrets)
  • Masquage dans logs via SecretsProvider (internal/config/secrets.go)

Docker

Build:

make docker-build             # Construit image Docker

Dockerfile:

  • Multi-stage build (Go 1.23-alpine → alpine:latest)
  • Non-root user (app:app)
  • Health check (/health)
  • Expose port 8080

Run:

make docker-run               # Build + run container

A.6 Points d'Intégration

Contrats d'API avec Autres Services

Chat Server (Rust):

  • Endpoint Backend → Chat : /api/v1/chat/token génère JWT pour WebSocket
  • Format Token : JWT avec sub (user_id UUID), iss (JWT_ISSUER), aud (JWT_AUDIENCE)
  • Secret Partagé : CHAT_JWT_SECRET (fallback: JWT_SECRET)
  • URL Chat Server : CHAT_SERVER_URL (défaut: http://localhost:8081)

Stream Server (Rust):

  • Endpoint Backend → Stream : Callback /api/v1/internal/tracks/:id/stream-ready
  • Format Token : JWT (même format que Chat)
  • URL Stream Server : STREAM_SERVER_URL (défaut: http://localhost:8082)

Frontend React:

  • Base URL : http://localhost:8080/api/v1
  • Auth : JWT Bearer tokens
  • CORS : Configuré via CORS_ALLOWED_ORIGINS (wildcard * interdit en production)

Auth (JWT/SSO)

JWT:

  • Algorithme : HS256 (strictement vérifié, none/RS256 rejetés)
  • Claims Requis : sub (user_id UUID), exp, iat, iss, aud, token_version
  • TTL : Access token 15min, Refresh token 30 jours
  • Révocation : Token versioning (incrément user.token_version → tous tokens invalides)

Sessions:

  • Stockage : DB (user_sessions table)
  • Validation : Obligatoire dans AuthMiddleware.authenticate()
  • Expiration : Configurable (défaut: 30 jours)

RBAC:

  • Rôles : user, admin, creator, premium, artist, producer, label
  • Permissions : Tables permissions, role_permissions, user_roles
  • Middleware : RequireAdmin(), RequirePermission(), RequireContentCreatorRole()

OAuth:

  • Partiel : Implémentation présente mais incomplète (TODO dans code)

Schéma DB / UUID / Conventions

IDs:

  • Format : UUID v4 (github.com/google/uuid)
  • Migration : Migration complète de int64 → uuid.UUID effectuée
  • Tables : Toutes tables utilisent id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Soft Delete:

  • Colonne : deleted_at TIMESTAMPTZ (nullable)
  • GORM : gorm.DeletedAt pour soft delete automatique
  • Tables : users, tracks, playlists, messages, etc.

Timestamps:

  • Colonnes : created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
  • GORM : gorm.Model (inclut CreatedAt, UpdatedAt, DeletedAt)

Foreign Keys:

  • Format : user_id UUID REFERENCES users(id) ON DELETE CASCADE
  • Indexes : Index automatiques sur foreign keys

PHASE B - SANTÉ TECHNIQUE

B.1 Build Status

Compilation:

  • ✅ Status : Code compile sans erreurs (go build ./... réussit)
  • ✅ Go Version : 1.23.8 (requis dans go.mod)
  • ⚠️ Warnings : Quelques warnings de dépendances obsolètes

Fichiers:

  • Total Go Files : 663 fichiers
  • Test Files : 221 fichiers (*_test.go)
  • Ratio Tests : ~33% (221/663)

B.2 Tests

Exécution:

make test                     # Tests unitaires

Résultats:

  • ⚠️ 3 Tests Échouent :
    • TestLoad_MissingRequiredVariable_DBPassword : Devrait panic mais ne panic pas
    • TestLoad_MissingRequiredVariable_JWTSecret : Devrait panic mais ne panic pas
    • TestNewConfig_RequiresJWTSecret : Devrait panic mais ne panic pas
  • ✅ Autres Tests : Passent (cached ou ok)

Couverture:

  • ⚠️ Non Mesurée Automatiquement : Pas de CI/CD avec coverage report
  • Commande : make test-coverage génère coverage.html

Types de Tests:

  • ✅ Unitaires : Présents dans chaque package (*_test.go)
  • ✅ Intégration : tests/integration/ (nécessite Redis)
  • ✅ Transactions : tests/transactions/ (tests transactionnels)

Fiabilité:

  • ⚠️ Race Conditions : Tests avec -race non exécutés automatiquement
  • ⚠️ Flaky Tests : Non identifiés (nécessite plusieurs runs)

B.3 Linting & Qualité Code

Linters:

  • ✅ golangci-lint : Configuré dans Makefile
  • ⚠️ Non Exécuté Automatiquement : Pas de CI/CD
  • Commande : make lint

Go Vet:

  • ✅ Configuré : make vet
  • ⚠️ Non Exécuté Automatiquement : Pas de CI/CD

Format:

  • ✅ go fmt : Configuré
  • ✅ goimports : Configuré dans Makefile
  • Commande : make format

TODO/FIXME:

  • ⚠️ 90 TODOs/FIXMEs trouvés dans le code
  • Fichiers Principaux :
    • internal/config/config.go : 6 TODOs
    • internal/services/job_service.go : 3 TODOs
    • internal/database/database.go : 4 TODOs
    • internal/api/api_manager.go : 4 TODOs

B.4 Gestion des Erreurs

Patterns:

  • ✅ AppError : Erreurs standardisées (internal/errors/errors.go)
  • ✅ Error Codes : Codes numériques (1000-9999) par catégorie
  • ✅ Error Wrapping : fmt.Errorf("...: %w", err) pour chaînage
  • ✅ HTTP Status Mapping : mapErrorCodeToHTTPStatus() dans internal/handlers/error_response.go

Problèmes:

  • ⚠️ P1-ERRORS : Panics non capturés dans certains handlers (recovery middleware présent mais peut manquer)
  • ⚠️ P2-ERRORS : Erreurs non loggées dans certains services (audit nécessaire)

Recovery:

  • ✅ Recovery Middleware : middleware.Recovery() présent
  • ✅ Sentry Recovery : middleware.SentryRecover() pour tracking erreurs

B.5 Conventions & Structure

Naming:

  • ✅ Cohérent : Go conventions respectées (PascalCase exports, camelCase privés)
  • ✅ Packages : Packages par domaine (auth, track, playlist, etc.)

Structure Dossiers:

  • ✅ Organisée : Séparation claire (handlers/, services/, repositories/, models/)
  • ⚠️ Duplication : Certains handlers dans internal/handlers/ ET internal/api/handlers/ (legacy?)

Séparation Couches:

  • ✅ Respectée : Handlers → Services → Repositories → DB
  • ⚠️ Couplage : Certains services appellent directement GORM (bypass repositories)

PHASE C - SÉCURITÉ

C.1 Secrets & Configuration

Secrets Hardcodés:

  • ✅ Aucun Trouvé : Grep password|secret|key|token ne révèle pas de secrets hardcodés
  • ✅ Variables d'Environnement : Tous secrets via env vars

Fichiers .env:

  • ⚠️ P0-SECURITY : .env peut être committé (vérifier .gitignore)
  • ✅ Masquage Logs : SecretsProvider masque secrets dans logs (internal/config/secrets.go)

Configuration:

  • ✅ Validation : Config.Validate() + ValidateForEnvironment() (stricte en production)
  • ⚠️ P0-SECURITY : getEnvRequired() retourne erreur (pas panic) → tests échouent car attendent panic
    • Fichier : internal/config/config.go:524-529
    • Impact : Tests incorrects (devraient vérifier erreur, pas panic)

C.2 Authentification & Autorisation

JWT Validation

Implémentation:

  • ✅ Algorithme : HS256 (HMAC) - sécurisé
  • ✅ Validation Signature : jwt.ParseWithClaims() avec secret
  • ✅ Validation Expiration : exp claim vérifié
  • ✅ Validation Session DB : SessionService.ValidateSession() appelé
  • ✅ Validation Claims : sub (user_id UUID), exp, iat, iss, aud vérifiés
  • ✅ Validation Algorithme : alg header vérifié (HS256 uniquement) - FIXÉ (internal/services/jwt_service.go:121-127)
  • ✅ Token Version : Vérifié dans AuthMiddleware.authenticate() (internal/middleware/auth.go:119-129)

Problèmes:

  • ✅ RÉSOLU : Validation aud/iss JWT stricte (jwt.WithIssuer(), jwt.WithAudience())
  • ✅ RÉSOLU : Token version vérifiée dans authenticate()

RBAC (Role-Based Access Control)

Implémentation:

  • ✅ FONCTIONNEL : RequireAdmin() utilise PermissionService.HasRole(..., "admin")
  • ✅ FONCTIONNEL : RequirePermission() utilise PermissionService.HasPermission()
  • ✅ FONCTIONNEL : RequireContentCreatorRole() vérifie rôles creator/premium/admin/artist/producer/label
  • ✅ Tables DB : permissions, role_permissions, user_roles existent

Routes Protégées:

  • ✅ /api/v1/admin/* : Protégé par RequireAdmin()
  • ✅ /api/v1/tracks (POST) : Protégé par RequireContentCreatorRole()
  • ✅ /api/v1/marketplace/products (POST) : Protégé par RequireContentCreatorRole()

Problèmes:

  • ⚠️ P1-SECURITY : Pas de vérification ownership sur certaines routes
    • Exemple: /api/v1/users/:id (PUT) - vérifier ownership ou admin
    • Exemple: /api/v1/tracks/:id (DELETE) - vérifier ownership ou admin
    • Fichiers : internal/api/router.go:248, internal/api/router.go:299

Sessions

Implémentation:

  • ✅ Sessions stockées en DB avec hash du token (pas token en clair)
  • ✅ Validation session obligatoire dans AuthMiddleware.authenticate()
  • ✅ Vérification expires_at et revoked_at
  • ✅ Vérification user_id match entre token et session

Problèmes:

  • ⚠️ P2-SECURITY : Pas de rotation automatique sessions (TTL fixe)
  • ⚠️ P2-SECURITY : Pas de détection sessions suspectes (multiples IPs, etc.)

C.3 Injection & Validation

SQL Injection

Protection:

  • ✅ GORM : Utilisé (parametrized queries par défaut)
  • ✅ Prepared Statements : Présents (internal/database/prepared_statements.go)
  • ✅ Pas de Raw Queries : Aucune raw query avec concaténation string identifiée
  • ✅ **Pas de SELECT *** : Bonne pratique respectée

Vérification:

  • ✅ 29+ fichiers avec requêtes SQL analysés
  • ✅ Toutes utilisent paramètres ($1, $2, etc.) ou GORM

Risque: ✅ FAIBLE - Bien protégé

Input Validation

Implémentation:

  • ✅ go-playground/validator/v10 présent
  • ✅ Validateurs: EmailValidator, PasswordValidator
  • ⚠️ P1-SECURITY : Validation pas utilisée partout
    • Exemples: Handlers peuvent accepter input non validé
    • Impact: Données invalides en DB, risque injection indirecte

Sanitization XSS:

  • ⚠️ P2-SECURITY : Pas de sanitization XSS systématique
    • Impact: XSS possible si données affichées côté frontend sans échappement

File Upload:

  • ✅ Validation type MIME (UploadValidator)
  • ✅ Validation taille fichier
  • ⚠️ P1-SECURITY : Scan antivirus ClamAV mentionné mais non vérifié
    • Fichier: go.mod contient github.com/dutchcoders/go-clamd
    • Impact: Fichiers malveillants peuvent être uploadés
    • Fichier : internal/handlers/upload.go - pas d'usage ClamAV trouvé

CORS

Implémentation:

  • ✅ CORS middleware présent (internal/middleware/cors.go)
  • ✅ Whitelist configurable via CORS_ALLOWED_ORIGINS
  • ✅ Wildcard * interdit en production (validation ValidateForEnvironment())

Problèmes:

  • ⚠️ P0-SECURITY : Si CORS_ALLOWED_ORIGINS vide, CORS middleware pas appliqué
    • Fichier: internal/api/router.go:68-74
    • Impact: CORS errors en browsers, mais pas de faille (pas de wildcard appliqué)
    • Fix: Logger warning (déjà fait) ou appliquer CORS restrictif par défaut

Headers CORS:

  • ✅ Access-Control-Allow-Origin: Origin spécifique (pas wildcard en prod)
  • ✅ Access-Control-Allow-Credentials: true
  • ✅ Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
  • ✅ Access-Control-Allow-Headers: Authorization, Content-Type

Rate Limiting

Implémentation:

  • ✅ Rate limiter global (middleware.RateLimiter avec Redis)
  • ✅ Rate limiter simple (middleware.SimpleRateLimiter sans Redis)
  • ✅ Rate limiter par endpoint (middleware.EndpointLimiter)
  • ✅ Rate limiting sur /api/v1/auth/login (via EndpointLimiter.LoginRateLimit())

Problèmes:

  • ✅ RÉSOLU : Rate limiting sur /auth/login présent (internal/api/router.go:193-195)
  • ⚠️ P2-SECURITY : Rate limiting uploads présent mais peut être contourné (IP spoofing)

Configuration:

  • ✅ Configurable via RATE_LIMIT_LIMIT et RATE_LIMIT_WINDOW
  • ✅ Headers X-RateLimit-* présents

C.4 Dépendances Vulnérables

Scan Requis:

  • ⚠️ P1-SECURITY : Pas de scan automatique vulnérabilités (govulncheck non intégré en CI)
  • ⚠️ P1-SECURITY : Pas de Dependabot/GitHub Security advisories configuré
  • ⚠️ Nombreuses dépendances obsolètes (30+ packages avec updates disponibles)

Commandes Recommandées:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

Versions Suspectes:

  • ⚠️ golang.org/x/crypto v0.37.0 - Vérifier vulnérabilités récentes
  • ⚠️ golang.org/x/net v0.39.0 - Vérifier vulnérabilités récentes
  • ⚠️ github.com/gin-gonic/gin v1.9.1 - Vérifier updates disponibles

C.5 Top 10 Risques Sécurité

  1. 🔴 P0-SECURITY: CORS pas appliqué si CORS_ALLOWED_ORIGINS vide (warning seulement)
  2. 🔴 P0-SECURITY: Tests config incorrects (attendent panic au lieu d'erreur)
  3. 🟠 P1-SECURITY: Scan antivirus ClamAV non vérifié (uploads)
  4. 🟠 P1-SECURITY: Validation input pas systématique (risque injection indirecte)
  5. 🟠 P1-SECURITY: Pas de vérification ownership sur routes PUT/DELETE
  6. 🟠 P1-SECURITY: Pas de scan automatique vulnérabilités (govulncheck)
  7. 🟡 P2-SECURITY: Pas de sanitization XSS systématique
  8. 🟡 P2-SECURITY: Pas de rotation automatique sessions
  9. 🟡 P2-SECURITY: Pas de détection sessions suspectes
  10. 🟡 P2-SECURITY: Rate limiting uploads peut être contourné (IP spoofing)

PHASE D - ROBUSTESSE & OBSERVABILITÉ

D.1 Logs Structurés

Implémentation:

  • ✅ Zap utilisé (go.uber.org/zap)
  • ✅ Logs structurés JSON en production
  • ✅ Niveaux: DEBUG, INFO, WARN, ERROR
  • ✅ Context: request_id, user_id, trace_id, span_id

Problèmes:

  • ⚠️ P1-OBSERVABILITY : Stack traces dans logs (peut exposer info sensible)
    • Fichier: internal/middleware/error_handler.go:145 (conditionnel via includeStackTrace)
    • Impact: Info sensible (chemins fichiers, code) dans logs prod
    • FIX PARTIEL : includeStackTrace désactivé en production (internal/api/router.go:63)
  • ⚠️ P2-OBSERVABILITY : Pas de redaction automatique PII (emails, user_ids dans logs)
  • ⚠️ P2-OBSERVABILITY : Logs peuvent être volumineux (stack traces en dev)

Corrélation:

  • ✅ request_id présent (middleware RequestID())
  • ✅ trace_id et span_id supportés (OpenTelemetry ready)
  • ⚠️ P2-OBSERVABILITY : OpenTelemetry pas complètement intégré (traces manquantes)

D.2 Métriques

Implémentation:

  • ✅ Prometheus intégré (github.com/prometheus/client_golang)
  • ✅ Endpoint /metrics exposé
  • ✅ Métriques erreurs (ErrorMetrics)
  • ✅ Métriques health checks (RecordHealthCheck)

Métriques Disponibles:

  • ✅ Erreurs par code (veza_errors_total{code, status})
  • ✅ Health checks latence (veza_health_check_latency_ms{service})
  • ✅ HTTP requests (via middleware Metrics())

Problèmes:

  • ⚠️ P2-OBSERVABILITY : Métriques business manquantes (tracks créés, users actifs, etc.)
  • ⚠️ P2-OBSERVABILITY : Pas de métriques DB pool (connections, wait time)
  • ⚠️ P2-OBSERVABILITY : Pas de métriques Redis (hit rate, latency)

D.3 Health Checks

Endpoints:

  • ✅ /health : Stateless, toujours {status: "ok"}
  • ✅ /healthz : Liveness probe
  • ✅ /readyz : Readiness probe (vérifie DB, Redis, RabbitMQ)
  • ✅ /status : Status complet (DB, Redis, Chat Server, Stream Server)

Implémentation:

  • ✅ Vérifications avec timeouts (5s DB, 5s Redis, 100ms Stream Server)
  • ✅ Latence mesurée et retournée
  • ✅ Status: ok, slow, error, degraded

Problèmes:

  • ⚠️ P1-ROBUSTNESS : /readyz peut échouer si Redis/RabbitMQ down (même en dev)
    • Fichier: internal/handlers/health.go:143-159
    • Impact: Kubernetes peut tuer le pod si readiness échoue
    • Fix: Mode dégradé si services optionnels down

D.4 Timeouts & Retries

Timeouts:

  • ✅ Global Handler Timeout : HANDLER_TIMEOUT (défaut: 30s)
  • ✅ Timeout Middleware : middleware.Timeout() appliqué globalement
  • ⚠️ P1-ROBUSTNESS : Timeout middleware appliqué 2 fois (duplication)
    • Fichier: internal/api/router.go:77-79
    • Impact: Redondant mais pas bloquant
  • ⚠️ P1-ROBUSTNESS : Pas de timeout DB configuré explicitement (utilise contexte)

Retries:

  • ✅ DB Retries : DBMaxRetries (défaut: 5) + DBRetryInterval (défaut: 5s)
  • ✅ RabbitMQ Retries : RabbitMQMaxRetries (défaut: 3) + RabbitMQRetryInterval (défaut: 2s)

Circuit Breakers:

  • ⚠️ P2-ROBUSTNESS : Pas de circuit breakers implémentés
    • Impact: Pas de protection contre cascading failures

D.5 Gestion de Charge

DB Pool:

  • ✅ Configuré: MaxOpenConns: 25, MaxIdleConns: 10, MaxLifetime: 5min, MaxIdleTime: 1min
  • ⚠️ P2-PERFORMANCE : Pas de métriques pool (connections in use, wait time)

Rate Limiting:

  • ✅ Global: 100 req/min par IP (configurable)
  • ✅ Par endpoint: Login 5 attempts/min (configurable)
  • ✅ Uploads: Rate limiting spécifique

Backpressure:

  • ⚠️ P2-ROBUSTNESS : Pas de backpressure explicite (dépend de rate limiting)

D.6 Migrations & Compatibilité

Stratégie Migrations:

  • ✅ 100% SQL : Migrations SQL dans migrations/*.sql
  • ✅ Transactions : Chaque migration dans transaction (atomicité)
  • ✅ Versioning : Table schema_migrations pour tracking
  • ✅ GORM Indexes : Indexes additionnels via GORM après migrations SQL

Compatibilité:

  • ✅ UUID Migration : Migration complète int64 → uuid.UUID effectuée
  • ✅ Soft Delete : Compatible avec GORM

Problèmes:

  • ⚠️ P2-ROBUSTNESS : Pas de rollback automatique (migrations SQL seulement)
    • Impact: Rollback manuel nécessaire en cas d'échec

PHASE E - PERFORMANCE & SCALABILITÉ

E.1 Hotspots Évidents

Allocations:

  • ⚠️ P2-PERFORMANCE : Copies de slices/strings dans certains handlers (audit nécessaire)
  • ⚠️ P2-PERFORMANCE : JSON marshalling peut être optimisé (streaming pour grandes réponses)

N+1 Queries:

  • ⚠️ P2-PERFORMANCE : Risque N+1 dans ListTracks() si relations chargées (audit nécessaire)
  • ✅ GORM Preload : Utilisé dans certains services (Preload("User"))

Locks:

  • ⚠️ P2-PERFORMANCE : Pas de locks identifiés (audit nécessaire pour concurrence)

E.2 Streaming

Buffering:

  • ✅ Chunked Upload : Implémenté (TrackChunkService)
  • ✅ Redis Cache : Utilisé pour chunks (si Redis enabled)

ffmpeg Pipeline:

  • ⚠️ P2-PERFORMANCE : Pas d'implémentation ffmpeg dans backend (délégué à Stream Server)

IO:

  • ⚠️ P2-PERFORMANCE : File I/O synchrone (peut bloquer goroutines)

E.3 Go-Specific Issues

Goroutine Leaks:

  • ⚠️ P1-ROBUSTNESS : Goroutines dans timeout middleware peuvent leak si handler ne termine pas
    • Fichier: internal/middleware/timeout.go:24-27
    • Impact: Memory leak potentiel
    • Fix: Context cancellation + cleanup goroutine

Context Propagation:

  • ✅ Context : Propagé dans handlers → services → repositories
  • ⚠️ P2-PERFORMANCE : Pas toujours utilisé pour timeouts DB

DB Pool Misuse:

  • ✅ Pool Configuré : MaxOpenConns, MaxIdleConns configurés
  • ⚠️ P2-PERFORMANCE : Pas de métriques pool pour monitoring

E.4 Optimisations Mesurables

  1. P2-PERFORMANCE : Ajouter métriques DB pool (connections, wait time)
  2. P2-PERFORMANCE : Optimiser JSON marshalling (streaming pour grandes réponses)
  3. P2-PERFORMANCE : Précharger relations dans ListTracks() (éviter N+1)
  4. P2-PERFORMANCE : File I/O asynchrone (goroutines pour uploads)
  5. P1-ROBUSTNESS : Fix goroutine leak dans timeout middleware

PHASE F - LISTE EXHAUSTIVE DES PROBLÈMES PRIORISÉS

Définition des Priorités

  • P0 : Faille sécurité exploitable / perte de données / crash prod / corruption / auth bypass / build cassé
  • P1 : Bugs fréquents / dette bloquante / erreurs de contrat inter-modules / manque de tests critiques
  • P2 : Qualité, maintenabilité, perf non critique, DX
  • P3 : Cosmétique, refactors non urgents

P0 - CRITIQUES (À CORRIGER IMMÉDIATEMENT)

MOD-P0-001: CORS Middleware Non Appliqué si CORS_ALLOWED_ORIGINS Vide

  • ID : MOD-P0-001
  • Titre : CORS middleware pas appliqué si CORS_ALLOWED_ORIGINS vide
  • Impact : CORS errors en browsers (requêtes bloquées). En production, si CORS_ALLOWED_ORIGINS vide (strict mode), CORS middleware n'est pas appliqué → requêtes cross-origin rejetées par navigateur (comportement attendu mais non documenté).
  • Preuve :
    • Fichier: internal/api/router.go:68-74
    • Code: if r.config != nil && len(r.config.CORSOrigins) > 0 { router.Use(middleware.CORS(...)) } else { logger.Warn(...) }
  • Cause Racine : Condition len(r.config.CORSOrigins) > 0 empêche application middleware si liste vide (strict mode).
  • Fix Minimal : Appliquer CORS middleware même si liste vide (middleware doit rejeter toutes origines sauf celles explicitement autorisées). OU documenter que liste vide = strict mode (pas de CORS).
  • Plan Validation :
    • Test: Requête cross-origin avec CORS_ALLOWED_ORIGINS="" → doit retourner erreur CORS
    • Commande: curl -H "Origin: http://evil.com" http://localhost:8080/api/v1/health → doit rejeter
  • Effet de Bord : Aucun (comportement attendu en strict mode)
  • Effort : S (1h)

MOD-P0-002: Tests Config Incorrects (Attendent Panic au lieu d'Erreur)

  • ID : MOD-P0-002
  • Titre : Tests config attendent panic mais getEnvRequired() retourne erreur
  • Impact : Tests échouent, confusion sur comportement attendu. Si config invalide, application doit crash au démarrage (acceptable) mais tests incorrects.
  • Preuve :
    • Fichiers: internal/config/config_test.go:137, 166, 315
    • Tests: TestLoad_MissingRequiredVariable_DBPassword, TestLoad_MissingRequiredVariable_JWTSecret, TestNewConfig_RequiresJWTSecret
    • Code: getEnvRequired() retourne error (ligne 524-529), pas panic
  • Cause Racine : Tests écrits avant implémentation ou changement de comportement.
  • Fix Minimal : Corriger tests pour vérifier erreur retournée au lieu de panic. OU modifier getEnvRequired() pour panic (mais moins idiomatique en Go).
  • Plan Validation :
    • Test: Exécuter make test → tests doivent passer
    • Commande: go test ./internal/config/... -v
  • Effet de Bord : Aucun (correction tests seulement)
  • Effort : S (30min)

MOD-P0-003: Timeout Middleware Appliqué 2 Fois (Duplication)

  • ID : MOD-P0-003
  • Titre : Timeout middleware appliqué 2 fois (lignes 77 et 79)
  • Impact : Redondant mais pas bloquant. Deux timeouts peuvent créer confusion (lequel s'applique?).
  • Preuve :
    • Fichier: internal/api/router.go:77-79
    • Code: router.Use(middleware.Timeout(r.config.HandlerTimeout)) (ligne 77) puis ligne 79 identique
  • Cause Racine : Copier-coller ou merge conflict non résolu.
  • Fix Minimal : Supprimer une des deux lignes (garder ligne 77).
  • Plan Validation :
    • Test: Vérifier qu'un seul timeout s'applique
    • Commande: grep -n "Timeout" internal/api/router.go → doit trouver 1 occurrence
  • Effet de Bord : Aucun (suppression duplication)
  • Effort : S (5min)

P1 - IMPORTANTS (À CORRIGER AVANT PROD)

MOD-P1-001: Scan Antivirus ClamAV Non Vérifié (Uploads)

  • ID : MOD-P1-001
  • Titre : Scan antivirus ClamAV mentionné mais non vérifié dans code upload
  • Impact : Fichiers malveillants peuvent être uploadés. Risque sécurité (malware, virus).
  • Preuve :
    • Fichier: go.mod contient github.com/dutchcoders/go-clamd
    • Fichier: internal/handlers/upload.go - pas d'usage ClamAV trouvé
  • Cause Racine : Dépendance présente mais intégration manquante.
  • Fix Minimal : Ajouter scan ClamAV dans UploadHandler.UploadFile() avant sauvegarde. Si ClamAV unavailable, rejeter upload (fail-secure).
  • Plan Validation :
    • Test: Uploader fichier EICAR (test virus) → doit être rejeté
    • Commande: curl -X POST -F "file=@eicar.txt" http://localhost:8080/api/v1/uploads → doit retourner 400
  • Effet de Bord : Uploads plus lents (scan nécessaire). Nécessite ClamAV daemon running.
  • Effort : M (4h)

MOD-P1-002: Validation Input Pas Systématique

  • ID : MOD-P1-002
  • Titre : Validation input avec go-validator pas utilisée partout
  • Impact : Données invalides en DB, risque injection indirecte, corruption données.
  • Preuve : Handlers peuvent accepter input non validé (audit complet nécessaire). Exemples: UpdateProfile, UpdateTrack.
  • Cause Racine : Validation manuelle au lieu de struct tags validate:"".
  • Fix Minimal : Ajouter struct tags validate:"" sur tous DTOs et middleware validation global. Exemple: type UpdateProfileRequest struct { Email string validate:"omitempty,email" }
  • Plan Validation :
    • Test: Envoyer requête avec email invalide → doit retourner 400 avec détails
    • Commande: curl -X PUT -d '{"email":"invalid"}' http://localhost:8080/api/v1/users/123 → doit valider
  • Effet de Bord : Requêtes invalides seront rejetées (comportement attendu)
  • Effort : M (8h)

MOD-P1-003: Pas de Vérification Ownership sur Routes PUT/DELETE

  • ID : MOD-P1-003
  • Titre : Pas de vérification ownership sur routes PUT/DELETE (users, tracks)
  • Impact : Utilisateurs peuvent modifier/supprimer ressources d'autres utilisateurs si ID connu. Risque sécurité (modification non autorisée).
  • Preuve :
    • Fichier: internal/api/router.go:248 - PUT /users/:id pas de vérification ownership
    • Fichier: internal/api/router.go:299 - PUT /tracks/:id pas de vérification ownership
    • Fichier: internal/api/router.go:300 - DELETE /tracks/:id pas de vérification ownership
  • Cause Racine : Middleware auth vérifie seulement authentification, pas ownership.
  • Fix Minimal : Ajouter vérification ownership dans handlers. Exemple: if track.UserID != userID && !isAdmin { return 403 }. OU middleware RequireOwnership().
  • Plan Validation :
    • Test: User A essaie modifier track de User B → doit retourner 403
    • Commande: curl -X PUT -H "Authorization: Bearer <token_user_a>" http://localhost:8080/api/v1/tracks/<track_id_user_b> → doit rejeter
  • Effet de Bord : Utilisateurs ne peuvent plus modifier ressources d'autres (comportement attendu)
  • Effort : M (6h)

MOD-P1-004: Pas de Scan Automatique Vulnérabilités (govulncheck)

  • ID : MOD-P1-004
  • Titre : Pas de scan automatique vulnérabilités (govulncheck) en CI/CD
  • Impact : Vulnérabilités non détectées automatiquement. Risque sécurité (exploitation vulnérabilités connues).
  • Preuve : Pas de CI/CD configuré. govulncheck présent dans Makefile mais pas exécuté automatiquement.
  • Cause Racine : Pas de CI/CD configuré (GitHub Actions, GitLab CI, etc.).
  • Fix Minimal : Ajouter étape CI/CD: govulncheck ./.... OU intégrer Dependabot/GitHub Security advisories.
  • Plan Validation :
    • Test: Exécuter govulncheck ./... → doit détecter vulnérabilités si présentes
    • Commande: make security → doit inclure govulncheck
  • Effet de Bord : Aucun (détection seulement)
  • Effort : S (2h pour CI/CD)

MOD-P1-005: Stack Traces dans Logs Prod (Partiellement Fixé)

  • ID : MOD-P1-005
  • Titre : Stack traces dans logs peuvent exposer info sensible (chemins fichiers, code)
  • Impact : Info sensible dans logs prod. Risque fuite données (chemins fichiers, structure code).
  • Preuve :
    • Fichier: internal/middleware/error_handler.go:145 - stack traces conditionnels
    • FIX PARTIEL : includeStackTrace désactivé en production (internal/api/router.go:63)
  • Cause Racine : Stack traces utiles en dev mais dangereux en prod.
  • Fix Minimal : Vérifier que includeStackTrace est bien false en production. Ajouter redaction automatique chemins fichiers si stack traces nécessaires.
  • Plan Validation :
    • Test: Erreur en production → logs ne doivent pas contenir stack traces
    • Commande: APP_ENV=production go run ... → vérifier logs
  • Effet de Bord : Aucun (déjà fixé partiellement)
  • Effort : S (1h pour vérification)

MOD-P1-006: /readyz Peut Échouer si Redis/RabbitMQ Down

  • ID : MOD-P1-006
  • Titre : /readyz peut échouer si Redis/RabbitMQ down (même en dev)
  • Impact : Kubernetes peut tuer le pod si readiness échoue. Service peut être marqué "not ready" même si DB OK (services optionnels down).
  • Preuve :
    • Fichier: internal/handlers/health.go:143-159
    • Code: Vérifie Redis et RabbitMQ même si REDIS_ENABLE=false ou RABBITMQ_ENABLE=false (à vérifier)
  • Cause Racine : Readiness vérifie tous services sans distinction optionnels/requis.
  • Fix Minimal : Mode dégradé si services optionnels down. /readyz doit retourner OK si DB OK et services optionnels down (mais status "degraded").
  • Plan Validation :
    • Test: Redis down, DB OK → /readyz doit retourner 200 avec status "degraded"
    • Commande: curl http://localhost:8080/api/v1/readyz → doit retourner OK même si Redis down
  • Effet de Bord : Service marqué "ready" même si services optionnels down (acceptable)
  • Effort : M (4h)

MOD-P1-007: Goroutine Leak Potentiel dans Timeout Middleware

  • ID : MOD-P1-007
  • Titre : Goroutines dans timeout middleware peuvent leak si handler ne termine pas
  • Impact : Memory leak potentiel. Goroutines non nettoyées → consommation mémoire croissante.
  • Preuve :
    • Fichier: internal/middleware/timeout.go:24-27
    • Code: go func() { c.Next(); close(done) }() - goroutine peut ne pas terminer si handler bloque
  • Cause Racine : Goroutine lancée sans garantie de cleanup si timeout.
  • Fix Minimal : Context cancellation + cleanup goroutine. Utiliser context.WithCancel() et annuler contexte si timeout.
  • Plan Validation :
    • Test: Handler qui bloque indéfiniment → goroutine doit être nettoyée après timeout
    • Commande: Stress test avec handlers lents → vérifier nombre goroutines (stable)
  • Effet de Bord : Aucun (fix memory leak)
  • Effort : M (3h)

P2 - QUALITÉ & MAINTENABILITÉ

MOD-P2-001: Pas de Sanitization XSS Systématique

  • ID : MOD-P2-001
  • Titre : Pas de sanitization XSS systématique
  • Impact : XSS possible si données affichées côté frontend sans échappement. Risque faible (backend ne génère pas HTML).
  • Preuve : Pas de sanitization trouvée dans handlers.
  • Cause Racine : Backend REST (JSON) ne génère pas HTML, sanitization côté frontend.
  • Fix Minimal : Documenter que sanitization doit être côté frontend. OU ajouter sanitization si endpoints génèrent HTML (ex: emails).
  • Plan Validation : N/A (backend REST)
  • Effet de Bord : Aucun
  • Effort : S (1h pour documentation)

MOD-P2-002: Pas de Rotation Automatique Sessions

  • ID : MOD-P2-002
  • Titre : Pas de rotation automatique sessions (TTL fixe)
  • Impact : Sessions longues (30 jours) sans rotation. Risque sécurité faible (tokens révoquables via token_version).
  • Preuve : Sessions ont TTL fixe, pas de rotation automatique.
  • Cause Racine : Design simple (TTL fixe).
  • Fix Minimal : Ajouter rotation automatique (renouveler session après X jours d'inactivité). OU documenter que révocation via token_version est suffisante.
  • Plan Validation : N/A (amélioration UX)
  • Effet de Bord : Aucun
  • Effort : M (4h)

MOD-P2-003: Pas de Détection Sessions Suspectes

  • ID : MOD-P2-003
  • Titre : Pas de détection sessions suspectes (multiples IPs, etc.)
  • Impact : Pas de détection compromission compte. Risque sécurité faible (détection proactive).
  • Preuve : Pas de détection trouvée.
  • Cause Racine : Feature non implémentée.
  • Fix Minimal : Ajouter détection (multiples IPs, géolocalisation, etc.) et alerter utilisateur. OU documenter comme future amélioration.
  • Plan Validation : N/A (feature additionnelle)
  • Effet de Bord : Aucun
  • Effort : L (8h)

MOD-P2-004: Métriques Business Manquantes

  • ID : MOD-P2-004
  • Titre : Métriques business manquantes (tracks créés, users actifs, etc.)
  • Impact : Monitoring business limité. Pas de visibilité sur métriques métier.
  • Preuve : Métriques Prometheus présentes pour erreurs/health, pas pour business.
  • Cause Racine : Focus sur métriques techniques.
  • Fix Minimal : Ajouter métriques business: veza_tracks_created_total, veza_users_active_total, etc.
  • Plan Validation :
    • Test: Créer track → métrique veza_tracks_created_total doit s'incrémenter
    • Commande: curl http://localhost:8080/api/v1/metrics | grep tracks_created
  • Effet de Bord : Aucun
  • Effort : M (6h)

MOD-P2-005: Pas de Métriques DB Pool

  • ID : MOD-P2-005
  • Titre : Pas de métriques DB pool (connections, wait time)
  • Impact : Monitoring DB limité. Pas de visibilité sur utilisation pool.
  • Preuve : Pas de métriques pool trouvées.
  • Cause Racine : Métriques pool non exposées.
  • Fix Minimal : Exposer métriques sql.DB.Stats() via Prometheus: veza_db_pool_open_connections, veza_db_pool_wait_count, etc.
  • Plan Validation :
    • Test: Stress test → métriques pool doivent refléter utilisation
    • Commande: curl http://localhost:8080/api/v1/metrics | grep db_pool
  • Effet de Bord : Aucun
  • Effort : M (4h)

MOD-P2-006: Pas de Métriques Redis

  • ID : MOD-P2-006
  • Titre : Pas de métriques Redis (hit rate, latency)
  • Impact : Monitoring Redis limité. Pas de visibilité sur performance cache.
  • Preuve : Pas de métriques Redis trouvées.
  • Cause Racine : Métriques Redis non exposées.
  • Fix Minimal : Exposer métriques Redis via Prometheus: veza_redis_hit_rate, veza_redis_latency_ms, etc.
  • Plan Validation :
    • Test: Requêtes avec cache → métriques Redis doivent refléter hits/misses
    • Commande: curl http://localhost:8080/api/v1/metrics | grep redis
  • Effet de Bord : Aucun
  • Effort : M (4h)

MOD-P2-007: Pas de Redaction Automatique PII dans Logs

  • ID : MOD-P2-007
  • Titre : Pas de redaction automatique PII (emails, user_ids dans logs)
  • Impact : PII dans logs (RGPD compliance). Risque faible si logs sécurisés.
  • Preuve : Logs peuvent contenir emails, user_ids sans redaction.
  • Cause Racine : Redaction PII non implémentée.
  • Fix Minimal : Ajouter redaction automatique PII dans logs (emails → ***@***, user_ids → hash). OU documenter que logs sont sécurisés.
  • Plan Validation :
    • Test: Logger email → logs ne doivent pas contenir email en clair
    • Commande: grep -r "email" logs/ → emails doivent être redactés
  • Effet de Bord : Aucun
  • Effort : M (6h)

MOD-P2-008: OpenTelemetry Pas Complètement Intégré

  • ID : MOD-P2-008
  • Titre : OpenTelemetry pas complètement intégré (traces manquantes)
  • Impact : Distributed tracing limité. Pas de visibilité sur traces complètes.
  • Preuve : trace_id et span_id supportés mais traces non générées.
  • Cause Racine : OpenTelemetry partiellement intégré.
  • Fix Minimal : Intégrer OpenTelemetry complet (traces, spans). OU documenter comme future amélioration.
  • Plan Validation : N/A (feature additionnelle)
  • Effet de Bord : Aucun
  • Effort : L (12h)

MOD-P2-009: Pas de Circuit Breakers

  • ID : MOD-P2-009
  • Titre : Pas de circuit breakers implémentés
  • Impact : Pas de protection contre cascading failures. Risque faible (retries présents).
  • Preuve : Pas de circuit breakers trouvés.
  • Cause Racine : Feature non implémentée.
  • Fix Minimal : Ajouter circuit breakers pour services externes (Chat Server, Stream Server). OU documenter comme future amélioration.
  • Plan Validation : N/A (feature additionnelle)
  • Effet de Bord : Aucun
  • Effort : M (8h)

MOD-P2-010: Pas de Rollback Automatique Migrations

  • ID : MOD-P2-010
  • Titre : Pas de rollback automatique migrations (migrations SQL seulement)
  • Impact : Rollback manuel nécessaire en cas d'échec. Risque faible (migrations transactionnelles).
  • Preuve : Migrations SQL n'ont pas de .down.sql correspondants.
  • Cause Racine : Stratégie 100% SQL sans down migrations.
  • Fix Minimal : Ajouter down migrations (.down.sql) OU documenter procédure rollback manuelle.
  • Plan Validation : N/A (amélioration DX)
  • Effet de Bord : Aucun
  • Effort : L (16h pour toutes migrations)

P3 - COSMÉTIQUE & REFACTORS

MOD-P3-001: 90 TODOs/FIXMEs dans Code

  • ID : MOD-P3-001
  • Titre : 90 TODOs/FIXMEs dans code
  • Impact : Dette technique. Maintenance difficile.
  • Preuve : Grep trouve 90 TODOs/FIXMEs.
  • Cause Racine : Features incomplètes, refactors différés.
  • Fix Minimal : Trier TODOs par priorité, créer issues GitHub, résoudre progressivement.
  • Plan Validation : N/A
  • Effet de Bord : Aucun
  • Effort : L (variable)

MOD-P3-002: Duplication Handlers (legacy + modern)

  • ID : MOD-P3-002
  • Titre : Duplication handlers (internal/handlers/ ET internal/api/handlers/)
  • Impact : Confusion, maintenance difficile.
  • Preuve : Handlers dans deux emplacements.
  • Cause Racine : Migration legacy → modern incomplète.
  • Fix Minimal : Consolider handlers dans internal/api/handlers/, supprimer internal/handlers/ (si possible).
  • Plan Validation : N/A
  • Effet de Bord : Aucun
  • Effort : M (8h)

MOD-P3-003: Couplage Services → GORM Direct

  • ID : MOD-P3-003
  • Titre : Certains services appellent directement GORM (bypass repositories)
  • Impact : Violation séparation couches. Maintenance difficile.
  • Preuve : Services utilisent db.GormDB directement.
  • Cause Racine : Refactor incomplet vers repositories.
  • Fix Minimal : Migrer services vers repositories. OU documenter exceptions.
  • Plan Validation : N/A
  • Effet de Bord : Aucun
  • Effort : L (variable)

PHASE G - PLAN D'EXÉCUTION

G.1 Checklist P0 (Ordre Strict)

  1. MOD-P0-001 : Fix CORS middleware (appliquer même si liste vide) - 1h
  2. MOD-P0-002 : Fix tests config (vérifier erreur au lieu de panic) - 30min
  3. MOD-P0-003 : Supprimer duplication timeout middleware - 5min

Total P0 : ~2h

G.2 Checklist P1 (Par Lots Cohérents)

Lot 1: Sécurité Uploads & Validation (1 sprint)

  1. MOD-P1-001 : Intégrer scan ClamAV (uploads) - 4h
  2. MOD-P1-002 : Validation input systématique - 8h
  3. MOD-P1-003 : Vérification ownership routes PUT/DELETE - 6h

Total Lot 1 : ~18h (2-3 jours)

Lot 2: Robustesse & Observabilité (1 sprint)

  1. MOD-P1-004 : Scan vulnérabilités CI/CD - 2h
  2. MOD-P1-005 : Vérifier stack traces logs prod - 1h
  3. MOD-P1-006 : Fix /readyz (mode dégradé) - 4h
  4. MOD-P1-007 : Fix goroutine leak timeout - 3h

Total Lot 2 : ~10h (1-2 jours)

Total P1 : ~28h (3-5 jours)

G.3 Quick Wins (≤ 1h chacun)

  1. MOD-P0-003 : Supprimer duplication timeout - 5min
  2. MOD-P1-004 : Ajouter govulncheck CI/CD - 2h (si CI/CD configuré)
  3. MOD-P2-001 : Documenter sanitization XSS - 1h

Total Quick Wins : ~3h

G.4 Tests à Ajouter en Priorité

  1. Tests Ownership : Vérifier que users ne peuvent pas modifier ressources d'autres
  2. Tests ClamAV : Vérifier rejet fichiers malveillants
  3. Tests Validation : Vérifier rejet input invalide
  4. Tests CORS : Vérifier comportement avec CORS_ALLOWED_ORIGINS vide
  5. Tests Timeout : Vérifier timeout middleware (pas de leak)

G.5 PR Plan

PR 1: Fix P0 Critiques

  • Titre : fix(security): Fix CORS middleware and config tests (P0)
  • Fichiers : internal/api/router.go, internal/config/config_test.go
  • Tests : Tests CORS, tests config
  • Taille : Petite (~200 lignes)

PR 2: Sécurité Uploads

  • Titre : feat(security): Add ClamAV scan for file uploads (P1)
  • Fichiers : internal/handlers/upload.go, internal/services/upload_validator.go
  • Tests : Tests ClamAV (EICAR)
  • Taille : Moyenne (~500 lignes)

PR 3: Validation Input

  • Titre : feat(validation): Add systematic input validation (P1)
  • Fichiers : DTOs, middleware validation
  • Tests : Tests validation tous endpoints
  • Taille : Grande (~1000 lignes)

PR 4: Ownership Verification

  • Titre : feat(security): Add ownership verification for PUT/DELETE (P1)
  • Fichiers : internal/api/router.go, handlers users/tracks
  • Tests : Tests ownership
  • Taille : Moyenne (~600 lignes)

PR 5: Robustesse

  • Titre : feat(robustness): Fix /readyz and goroutine leak (P1)
  • Fichiers : internal/handlers/health.go, internal/middleware/timeout.go
  • Tests : Tests health checks, tests timeout
  • Taille : Moyenne (~400 lignes)

PR 6: Observabilité (P2)

  • Titre : feat(observability): Add business and DB pool metrics (P2)
  • Fichiers : internal/metrics/, handlers
  • Tests : Tests métriques
  • Taille : Moyenne (~500 lignes)

G.6 Estimation Totale

  • P0 : 2h
  • P1 : 28h
  • P2 : ~60h (optionnel)
  • P3 : Variable (refactors)

Total Critique (P0+P1) : ~30h (1 semaine développeur)

CONCLUSION

Module : veza-backend-api (Backend Go)
Status Global : ✅ Fonctionnel avec améliorations nécessaires

Points Forts :

  • ✅ Architecture solide (handlers → services → repositories)
  • ✅ Sécurité JWT bien implémentée (HS256, token versioning, sessions DB)
  • ✅ RBAC fonctionnel
  • ✅ Observabilité de base (logs structurés, Prometheus, Sentry)
  • ✅ Migrations SQL transactionnelles

Points Faibles :

  • ⚠️ 3 problèmes P0 (CORS, tests, duplication)
  • ⚠️ 7 problèmes P1 (sécurité uploads, validation, ownership, robustesse)
  • ⚠️ 10+ problèmes P2 (observabilité, performance)

Recommandation : Corriger P0 immédiatement, puis P1 avant production, P2 progressivement.

Fin du Rapport