Résumé coaching 9

ANALYSE DE SECURITE
+ Le groupe a effectué et documenté sur le wiki une analyse de sécurité correcte, en identifiant les biens à protéger et en estimant les menaces et les risques associés.
+ Le groupe a identifié des contre-mesures adéquates pour l'ensemble des menaces identifiées.  
+ Le groupe connait et documente les limites de son travail de sécurisation (risques résiduels, …)
+ Le groupe a réfléchi au suivi des aspects sécurité du projet tout au long du cycle de vie du projet
+ Un diagramme de flux de données est attendu
	
SECURISATION	
+ Le groupe a mis en place les éléments de sécurité demandés dans le cadre du cours. Le groupe justifie et implémente correctement les mesures de sécurité au niveau du serveur (Utilisation https, version à jour / patchée, réflexion sur le hardening du serveur -par ex : pas d’autre port ouvert-, gestion des connexions et sessions, disponibilité, …), au niveau logiciel ( Librairies / Framework utilisés à jour, XSS, SQLi,gestion/stockage des mots de passe, ... ) et de la DB ( Inaccessible de l’extérieur, permissions / rôles définis adéquatement, backup, …)
	
VALIDATION DE LA SECURITE
+ Les étudiants ont utilisé des outils extérieurs pour valider la sécurisation de leur site, et présentent les résultats sur le wiki
+ Les étudiants ont compris, interprété et pris en compte les retours donnés par les outils extérieurs et corrigé les failles de sécurité éventuellement identifiées
	
ASPECTS LEGAUX	
+ Le wiki présente les contraintes légales auquel est soumis le site web (notamment RGPD)
+ Le wiki présente ce qui a été mis en place, ou aurait dû être mis en place, pour respecter le prescrit légal (traitement des données, backup, …)

1. Analyse de la sécurité

1.1 Biens à protéger

Élément	Pourquoi le protéger ?	Principes concernés
Code source	Empêcher l’injection de code malveillant ou le vol de logique	Intégrité, confidentialité
Base de données	Contient les utilisateurs, réservations, tables, horaires	Confidentialité, intégrité
Serveur backend	Point d’entrée de l’API, vulnérable aux attaques réseaux	Disponibilité, intégrité

---

1.2 Risques

Élément	Menace	Probabilité	Impact	Risque global
Base de données	Injection SQL, accès non autorisé	Moyenne	Élevé	Élevé
Serveur API	Déni de service, exploit Node	Faible	Élevé	Moyen
Code source	Mauvaise gestion GitHub	Moyenne	Moyen	Moyen
Sessions	Vol de token JWT	Moyenne	Moyen	Moyen

---

1.3 Contre-mesures

Menace	Contre-mesure	Implémenté ?	Détails
Injection SQL	Paramétrage strict, requêtes préparées	✅	Utilisation de pg avec query sécurisées
Accès DB non autorisé	Pas d’accès externe, mot de passe fort	✅	DB Docker isolée, env vars
Vol de sessions JWT	Expiration, rotation, HTTPS obligatoire	✅	JWT avec expiration
Failles via dépendances	Mise à jour régulière (npm audit)	✅	npm audit fix périodique
Exploit backend	Vérification des entrées, types	✅	TypeScript + Zod/validators

---

1.4 Suivi de la sécurisation

• Logs : journaux serveur visibles via console et logs de conteneur Docker
• Surveillance : erreurs visibles pendant les tests et développement
• Amélioration continue :
  • Audit via npm audit
  • Tests manuels
  • Possibilité future d’ajouter un outil comme Fail2Ban ou Sentry
• Responsabilité : chaque membre veille sur sa partie ; relecture des PRs critiques

---

1.5 Diagramme de flux de données

📎 [À intégrer depuis draw.io ou diagrams.net]

• Communication sécurisée en HTTPS
• Flux entre : utilisateur ⇄ Frontend ⇄ API ⇄ PostgreSQL
• Raspberry Pi Pico communique avec l’API via des requêtes REST POST

---

2. Sécurisation

• HTTPS activé via configuration NGINX (ou en local selon contexte)
• Pas de ports ouverts inutiles (exposition contrôlée en dev)
• JWT utilisé pour protéger toutes les routes utilisateurs
• Mots de passe hashés via bcrypt
• Variables sensibles stockées dans .env
• Accès à la base PostgreSQL restreint à localhost/Docker network
• Linter (Prettier) pour détecter erreurs syntaxiques
• API REST avec validation d’entrée (via TypeScript)

---

3. Validation de la sécurité

• Utilisation de npm audit, eslint, et docker logs
• Vérification manuelle des failles types :
  • Injection SQL (non reproductible grâce à requêtes paramétrées)
  • XSS (aucune donnée injectée dans le DOM côté client)
• Aucun pentest tiers effectué mais validations internes par tests manuels
• Suivi des failles connues via GitHub Dependabot

---

4. Cadre légal

4.1 Contraintes légales (RGPD)

• Données utilisateurs (nom, prénom, mail, date naissance)
• Droit à la suppression (delete user)
• Pas de collecte de données sensibles (carte, téléphone, etc.)
• Principe de minimisation appliqué

4.2 Mise en œuvre

• Possibilité de suppression de compte
• Stockage sécurisé, accès limité
• Pas de logs utilisateurs conservés inutilement
• Données non partagées à des tiers

---

5. Bilan et limites

• ✔️ Les mesures actuelles sont suffisantes pour un projet académique

• 🔐 Points forts :

  • Authentification JWT
  • Pas de faille critique connue
  • Environnement cloisonné

• ⚠️ Limites :

  • Pas de logging structuré centralisé
  • Pas de rate-limiting
  • Pas de suivi automatique d’activité suspecte
  • Pas de sauvegarde automatisée de la DB

➡️ En production, il faudrait :

• Ajouter rate limiting
• Mettre en place un système de logs type Sentry
• Mettre en place un système de backup journalier
• Appliquer une politique de mot de passe plus stricte