Revue de sécurité avant ouverture au public

Audit de l'application avant sa première publication sur internet.
Correctifs immédiats, peu coûteux et sans changement de comportement
en dev :

- Le backend refuse de démarrer en `ENVIRONMENT=production` si
  `JWT_SECRET` est vide, trop court ou égal à la valeur par défaut
  versionnée dans `.env.example` — sinon n'importe qui pourrait forger
  un jeton de session valide (y compris pour un compte COORDINATION)
  sans jamais s'authentifier. Testé (`test_config.py`).
- Avertissement au démarrage si `EMAIL_ENABLED=false` en production :
  dans ce cas le jeton de lien magique est journalisé en clair (confort
  de dev, cf. `api/auth.py`) — un identifiant de connexion en clair dans
  les logs du conteneur en public serait un vrai problème.
- `frontend/nginx.conf` : plus de journal d'accès (la route
  `/connexion?token=…` y ferait apparaître le jeton de lien magique en
  clair), en-têtes `X-Content-Type-Options`, `X-Frame-Options`,
  `Referrer-Policy` (empêche aussi la fuite de ce même jeton vers
  Google Fonts via l'en-tête Referer), `server_tokens off`.
- `deploy/Caddyfile.benevoles` : mêmes en-têtes côté reverse proxy
  public, plus `Strict-Transport-Security`.
- `deploy/README.md` : check-list sécurité avant ouverture (secret,
  SMTP, ne jamais mettre en production la base de démo `app.seed` — le
  mot de passe du compte coordination y est versionné en clair —,
  limites connues comme l'absence de rate-limiting sur `/auth/*`).

Points vérifiés sans modification nécessaire : autorisation par rôle et
cloisonnement par édition cohérents sur tous les endpoints (`owned_or_404`
+ vérification d'édition partout), mots de passe bcryptés, jetons de
lien magique à usage unique haché en base (256 bits d'entropie), pas de
PII/jeton dans les logs applicatifs (RGPD déjà en place), pas
d'injection de gabarit dans les emails (substitution sur liste blanche,
pas de `.format()`), pas d'injection d'en-tête SMTP (`EmailMessage` du
socle Python), pas de `dangerouslySetInnerHTML` côté front, jeton JWT
en `Authorization: Bearer` (pas de cookie ⇒ pas de CSRF), `.env` jamais
versionné, dépendances à jour.

Restent des choix à trancher avec l'utilisateur plutôt qu'à décider
seul (compromis effort/risque) : rate-limiting sur les endpoints
d'authentification, désactivation de `/docs` en production, conteneurs
non-root.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017uUsRg7XzopkCPWimwg9ZM

deploy/Caddyfile.benevoles

@@ -9,6 +9,16 @@
 benevoles.mon-domaine.fr {
     encode zstd gzip
 
+    # En-têtes de sécurité de base pour une appli publique. HSTS : Caddy gère
+    # le certificat et la redirection HTTP→HTTPS, mais n'ajoute pas ce header
+    # tout seul.
+    header {
+        Strict-Transport-Security "max-age=31536000; includeSubDomains"
+        X-Content-Type-Options "nosniff"
+        X-Frame-Options "DENY"
+        Referrer-Policy "strict-origin-when-cross-origin"
+    }
+
     # API : même préfixe `/api` que le proxy Vite en développement, retiré
     # avant de transmettre au backend (qui expose ses routes sous
     # `/editions/...`, pas `/api`).

deploy/README.md

@@ -15,6 +15,28 @@ serveur** (service système, hors de ce dépôt) reçoit le trafic public sur
 443 et reverse-proxy vers les deux conteneurs, qui n'écoutent que sur
 `127.0.0.1`.
 
+## Avant d'ouvrir au public — check-list sécurité
+
+- `JWT_SECRET` : une vraie valeur générée (`openssl rand -hex 32`), jamais la
+  valeur par défaut de `.env.example`. Le backend refuse de démarrer en
+  `ENVIRONMENT=production` sinon (`app/config.py:check_production_secrets`).
+- `EMAIL_ENABLED=true` avec un SMTP qui fonctionne (`docker compose run --rm
+  backend uv run python -m app.email.check <destinataire>` pour vérifier) —
+  sinon les liens magiques sont journalisés en clair au lieu d'être envoyés
+  (le backend avertit au démarrage tant que c'est le cas, voir plus bas).
+- Édition créée via `python -m app.bootstrap` (étape 3), **jamais** via
+  `python -m app.seed` : ce dernier crée un compte de démonstration
+  (`coordination@lucioles.test`) avec un mot de passe versionné dans le
+  dépôt — un vrai identifiant de connexion COORDINATION public si la base de
+  démo devient la base de production.
+- `CORS_ORIGINS` : sans objet ici tant que le frontend appelle l'API en
+  même origine via `/api/*` (voir le vhost Caddy, étape 5) — à ne renseigner
+  que si un autre client (domaine séparé, appli mobile) doit appeler l'API
+  directement.
+- Aucun rate-limiting sur `/auth/login` ni `/auth/magic-link` à ce stade
+  (pas de verrouillage de compte, pas de throttling) — acceptable pour une
+  petite équipe connue, mais à surveiller si l'URL circule plus largement.
+
 ## Étape 0 — pousser le dépôt sur GitLab
 
 ```bash
@@ -54,7 +76,10 @@ PUBLIC_BASE_URL=https://benevoles.mon-domaine.fr
 
 # Emails (récapitulatifs de planning + liens de connexion). Laisser
 # EMAIL_ENABLED=false tant que le SMTP n'est pas prêt : les emails sont alors
-# seulement journalisés.
+# seulement journalisés — un jeton de lien magique en clair dans les logs du
+# conteneur permet de se connecter à la place de n'importe qui, donc à
+# repasser à true avant l'ouverture au public (le backend affiche un
+# avertissement au démarrage tant que c'est le cas).
 EMAIL_ENABLED=true
 SMTP_HOST=smtp.mon-domaine.fr
 SMTP_PORT=587