Refactoring

SECURITY.md

@@ -0,0 +1,33 @@
+# 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é.
+
+## Endpoints sensibles
+
+- **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`.
+
+## Webhook Wave
+
+- **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.
+
+## Secrets et configuration
+
+- **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.
+
+## Validation des entrées
+
+- 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.
+
+## Bonnes pratiques
+
+- 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).