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

backend/tests/test_config.py

@@ -0,0 +1,40 @@
+"""Garde-fou : un secret JWT par défaut/vide/trop court ne doit jamais tourner
+en production (n'importe qui pourrait forger un jeton, y compris pour un
+compte COORDINATION) — voir `app/config.py:check_production_secrets`."""
+
+import pytest
+from pydantic import ValidationError
+
+from app.config import Settings
+
+_OK_SECRET = "x" * 32
+
+
+def test_dev_secret_refused_in_production():
+    with pytest.raises(ValidationError):
+        Settings(
+            environment="production",
+            jwt_secret="dev-insecure-secret-change-me-please-32b",
+        )
+
+
+def test_empty_secret_refused_in_production():
+    with pytest.raises(ValidationError):
+        Settings(environment="production", jwt_secret="")
+
+
+def test_short_secret_refused_in_production():
+    with pytest.raises(ValidationError):
+        Settings(environment="production", jwt_secret="trop-court")
+
+
+def test_proper_secret_accepted_in_production():
+    settings = Settings(environment="production", jwt_secret=_OK_SECRET)
+    assert settings.jwt_secret == _OK_SECRET
+
+
+def test_dev_secret_allowed_outside_production():
+    # Confort de dev : le défaut versionné ne doit pas empêcher de démarrer
+    # en local ou en CI.
+    settings = Settings(environment="development")
+    assert settings.is_production is False