34 lines
2.8 KiB
Markdown
34 lines
2.8 KiB
Markdown
# 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).
|