# 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).