AdamThomasandClaude Sonnet 5
89e74e5ec7
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
35 lines
1.3 KiB
Caddyfile
35 lines
1.3 KiB
Caddyfile
# Bloc à ajouter au Caddyfile existant du serveur (ex. /etc/caddy/Caddyfile,
|
|
# ou un fichier importé par lui — voir deploy/README.md). Remplacer le nom de
|
|
# domaine par le vôtre. Caddy gère seul le certificat HTTPS (Let's Encrypt).
|
|
#
|
|
# Le frontend (nginx, port 8080) et le backend (port 8000) écoutent tous les
|
|
# deux sur 127.0.0.1 uniquement (voir docker-compose.prod.yml) : ce vhost est
|
|
# leur unique porte d'entrée publique.
|
|
|
|
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`).
|
|
handle /api/* {
|
|
uri strip_prefix /api
|
|
reverse_proxy 127.0.0.1:8000
|
|
}
|
|
|
|
# Reste de l'application : le frontend statique (nginx).
|
|
handle {
|
|
reverse_proxy 127.0.0.1:8080
|
|
}
|
|
}
|