# Audit Codex du 2025-11-27 ## Priorités critiques - Retirer les secrets versionnés : supprimer du dépôt et régénérer les clés (ex. `backend-api/faildaily-8efdd-firebase-adminsdk-fbsvc-09630fc557.json`, .env), puis utiliser un store de secrets. - Durcir l’authentification : mots de passe plus stricts, blocage sur tentatives multiples, durée et rotation des JWT, envisager MFA pour l’admin. - Réduire la surface CORS : limiter aux domaines publics exacts, éviter `credentials=true` sur des origins de développement. - Resserer le rate limiting en prod (valeurs actuelles très hautes en mode dev), valider que `NODE_ENV=production` est bien appliqué. - Sécuriser l’accès aux médias : URLs opaques/signées ou contrôle d’accès pour les uploads, éviter l’exposition directe par nom de fichier. ## Autres chantiers importants - Forcer un pipeline de migrations (éviter les créations de tables “à la volée” au démarrage) et contrôler les droits SQL en prod. - Vérifier l’obligation de vérification email / complétion de profil avant usage ; clarifier le flux d’âge/consentement. - CSP/HTTPS : durcir la CSP (réduire `unsafe-inline`), s’assurer que le reverse proxy force HTTPS (HSTS déjà activé). - Opérations : ajouter monitoring, alerting, sauvegardes/restauration testées, journaux d’accès sécurisés. - Tests et qualité : exécuter et fiabiliser les suites Jest/Karma, ajouter e2e sur staging, lancer `npm audit` et corriger les vulnérabilités. ## Étapes recommandées avant bêta 1) Assainir les secrets et redéployer avec clés régénérées. 2) Configurer CORS/rate limit/HTTPS correctement en staging. 3) Mettre en place le pipeline de migrations et verrouiller les droits DB. 4) Revue sécurité ciblée (auth/session/upload) + tests d’intrusion légers. 5) Exécuter toutes les suites de tests + audit deps, corriger les alertes. 6) Activer monitoring/alerting et un plan de rollback avant d’ouvrir aux bêta-testeurs. Secrets exposés (critique) : un jeton de service Firebase admin est versionné (backend-api/faildaily-8efdd-firebase-adminsdk-fbsvc-09630fc557.json) et plusieurs .env sont dans le repo. À traiter comme compromis : supprimer des commits publics, régénérer/rotater toutes les clés concernées et utiliser un store de secrets. Surface CORS trop large (backend-api/server.js): credentials=true avec une whitelist comprenant tous les localhost et un paramètre CORS_ORIGIN injectable. En prod, limiter strictement aux domaines publics réels. Rate limiting faible si NODE_ENV mal réglé : valeur par défaut development → 100k requêtes/15min (backend-api/server.js). En prod il faut NODE_ENV=production + valeurs max adaptées (sinon DoS possible). Politique d’authentification rudimentaire (backend-api/src/controllers/authController.js et middleware/auth.js): mot de passe min 6 chars, pas de MFA, pas de rotation/invalidation de tokens, durée JWT 24h, pas de blocage par IP/utilisateur sur échecs répétés (seul rate-limit global). Renforcer avant bêta. Uploads servis publiquement sans contrôle d’accès (backend-api/server.js + src/routes/upload.js) et noms de fichiers contenant l’ID utilisateur. Les avatars/fails sont récupérables si l’URL est devinée; prévoir URLs opaques signées ou vérification d’accès, et revoir le cache très long appliqué. Enregistrement : la vérification d’email n’est pas imposée et registrationCompleted est initialisée à 1 si birthDate absente (authController.js), ce qui permet des comptes non vérifiés. À clarifier selon votre modèle de confiance. Sécurité HTTP : CSP autorise unsafe-inline pour les styles (server.js), HSTS activé mais aucune redirection HTTPS forcée ici; vérifier que le reverse-proxy force HTTPS et que la CSP est compatible avec le front mais la plus stricte possible. Gouvernance/ops : création de tables “à la volée” au démarrage (authController.ensure*Table) nécessite des droits DDL en prod et complique les migrations; prévoir un vrai pipeline de migrations. Pas de mention de monitoring, alerting, ni sauvegardes/restaurations testées. Tests/qualité : il y a des suites Jest côté backend et Karma/Angular côté front, mais non exécutées ici; aucune garantie de couverture. Un audit de dépendances (npm audit), une campagne d’intrusion et des tests e2e sur un environnement staging sont indispensables avant bêta. En l’état je ne considérerais pas l’application “sûre et complète” pour des bêta-testeurs réels sans : rotation/suppression des secrets exposés, durcissement de l’authentification, resserrage CORS/rate-limit, protection des médias, vérification email, pipeline de migrations/tests/monitoring et une revue sécurité plus exhaustive. Prochaine étape : corriger les points critiques ci-dessus, exécuter npm test (backend et frontend) + npm audit, puis déployer en staging avec supervision avant d’ouvrir à des bêta-testeurs. c'est quoi ça? Secrets manager si possible (Vault, AWS/GCP/Azure secrets, ou au moins un store chiffré). Un “secrets manager” est un service fait pour stocker et distribuer tes mots de passe/clefs de façon sécurisée (chiffrage, contrôle d’accès, rotation, audit). Exemples courants : HashiCorp Vault (on-prem ou managé) AWS Secrets Manager / Parameter Store GCP Secret Manager Azure Key Vault Avantages : secrets chiffrés au repos, accès par rôle, rotation automatisable, journalisation des accès. Tu les récupères à l’exécution (via SDK/CLI ou variables d’environnement injectées) plutôt que de laisser un fichier .env en clair sur le disque. Pour un setup Docker simple sans cloud : au minimum un fichier .env non versionné, chmod 600, hors image, ou docker secrets pour éviter que les secrets traînent en clair.