Sécurité – AfterWork Backend

Authentification et autorisation

Super Admin : Les opérations réservées au super administrateur (stats admin, modification de rôle utilisateur, impersonation) exigent le header X-Super-Admin-Key dont la valeur doit correspondre à la propriété afterwork.super-admin.api-key (ou SUPER_ADMIN_API_KEY en production). À configurer uniquement côté serveur, jamais exposée au client.
Utilisateurs / rôles : À ce jour, l’API ne repose pas sur JWT/OAuth pour les endpoints métier. En production, il est recommandé d’ajouter un filtre ou une ressource qui dérive l’identité (userId) du token (JWT/session) et de ne pas faire confiance au userId passé dans l’URL (ex. GET /notifications/user/{userId}). L’userId utilisé doit être celui de l’utilisateur authentifié.

Notifications (/notifications/user/{userId}) : En l’état, tout appelant peut demander les notifications d’un autre utilisateur en changeant userId. En production, remplacer userId par l’identifiant issu du contexte d’authentification (JWT/subject).
Admin : AdminStatsResource et les endpoints de modification de rôle dans UsersResource sont protégés par X-Super-Admin-Key.

Signature : Si la propriété wave.webhook.secret (ou WAVE_WEBHOOK_SECRET) est renseignée, le endpoint /webhooks/wave vérifie le header X-Wave-Signature (HMAC-SHA256 du body avec ce secret). Sans secret configuré, la vérification est désactivée (acceptable uniquement en dev/test).
Production : Configurer systématiquement WAVE_WEBHOOK_SECRET avec le secret fourni par Wave pour éviter les appels forgés.

Base de données : Utiliser les variables d’environnement (ex. DB_USERNAME, DB_PASSWORD) ou le profil Quarkus ; ne pas committer de mots de passe en clair.
Wave : WAVE_API_KEY et WAVE_WEBHOOK_SECRET via variables d’environnement.
Email (SMTP) : MAILER_USERNAME, MAILER_PASSWORD (et optionnellement MAILER_FROM, MAILER_HOST, etc.) via variables d’environnement.
Super Admin : SUPER_ADMIN_EMAIL, SUPER_ADMIN_PASSWORD, SUPER_ADMIN_API_KEY pour la production.

Les DTOs utilisent Bean Validation (@Valid, @NotNull, @Size, @Email, @Pattern) sur les endpoints principaux (création utilisateur, authentification, établissements, abonnements, etc.). Conserver et étendre ces contraintes sur tout nouvel endpoint.

Répondre par des codes HTTP adaptés (401 si non autorisé, 403 si interdit, 404 si ressource absente).
Ne pas logger de secrets (tokens, mots de passe, clés API).
En production, utiliser HTTPS et limiter l’exposition des headers sensibles (CORS, sécurisation des headers).