# Modèle de sécurité — Immbot AI

## Authentification

- **Sessions serveur** : cookie `immbot_session` httpOnly, `SameSite=Lax`, `Secure` en production,
  identifiant aléatoire 256 bits, **haché (SHA-256) avant stockage** dans la table `sessions`
  (un vol de la BD ne permet pas de rejouer une session). Expiration 14 jours glissants,
  révocation à la déconnexion et depuis l'admin.
- **Mots de passe** : bcrypt (coût 12) via bcryptjs. Politique : ≥ 10 caractères. `admin123`
  explicitement refusé comme mot de passe permanent.
- **Compte initial** : créé par script de seed depuis `INITIAL_ADMIN_USERNAME` /
  `INITIAL_ADMIN_PASSWORD` (défauts admin/admin123), champ `must_change_password=1` →
  redirection forcée vers le changement de mot de passe, bannière d'avertissement tant que
  le mot de passe initial est actif. `DISABLE_INITIAL_ADMIN=true` en production le désactive.
- **Limitation des tentatives** : 8 échecs / 15 min par (IP + identifiant), à mémoire serveur +
  journalisées dans `auth_events` (connexions, échecs, changements de mot de passe, déconnexions).
- **Récupération** : changement par l'utilisateur (mot de passe actuel requis) ; réinitialisation
  par l'admin (mot de passe temporaire + changement forcé). Pas de courriel en v1 (documenté).
- **CSRF** : mutations via `fetch` même origine + vérification systématique de l'en-tête
  `Origin`/`Sec-Fetch-Site` sur toutes les routes mutantes + cookies SameSite. Pas de formulaires
  cross-site.
- **SSO futur** : la table `users` porte `auth_provider` (`local` aujourd'hui) et un identifiant
  externe nullable — l'ajout d'OIDC (Microsoft/Google/UQO) n'exige pas de migration.

## Autorisation

- Rôles : `student` < `instructor` < `admin` (l'admin a tout ; l'instructeur a la pédagogie et le
  contenu, pas la gestion des utilisateurs).
- **Contrôle d'accès par cours** : table `enrollments` ; toute requête chat/RAG/apprentissage vérifie
  l'inscription au cours visé, côté serveur.
- **Espaces de connaissances** : chaque fragment porte `space`
  (`official-imm1003`, `official-imm1033`, `student-temporary-upload`, `student-persistent-files`,
  `instructor-private`, `general-knowledge`). Les requêtes étudiantes ne touchent jamais
  `instructor-private` ni les téléversements d'un autre étudiant (filtre SQL systématique, testé).
- Routes `/admin` et `/api/admin/*` : middleware + revérification du rôle dans chaque handler.

## Secrets et données

- `OPENROUTER_API_KEY` uniquement côté serveur (routes API) ; jamais dans un composant client,
  jamais journalisée. `.env` gitignoré ; `.env.example` sans valeurs réelles.
- Journaux structurés sans secrets ni contenu de mot de passe ; les messages d'erreur client ne
  fuient pas les détails internes.
- Données étudiantes : minimisation (nom d'utilisateur, courriel optionnel) ; les statistiques
  professeur sont **agrégées et anonymisées** (seuil de 3 étudiants minimum avant affichage d'un
  agrégat) ; le contenu individuel n'est jamais montré.
- `submissions.db` du prototype et le matériel d'examen : exclus / `instructor-private` (voir
  repository-analysis.md).
- Sauvegardes : `scripts/backup.sh` (copie datée de `data/` hors uploads temporaires).

## Défenses applicatives

- Validation zod de toutes les entrées API ; limites de taille (messages 32 k, uploads 25 Mo,
  types MIME vérifiés par signature).
- Requêtes SQL exclusivement préparées (aucune concaténation).
- Rendu Markdown sans HTML brut (`skipHtml`) → pas de XSS via réponses de modèle.
- En-têtes : CSP (script-src 'self'), X-Content-Type-Options, Referrer-Policy, X-Frame-Options DENY.
- Injection de prompt : le contenu récupéré et les fichiers étudiants sont encadrés de délimiteurs
  et le prompt système précise qu'ils sont des **données**, pas des instructions ; la validation de
  citations empêche l'exfiltration de fragments non autorisés (le serveur ne fournit au modèle que
  les fragments auxquels l'utilisateur a déjà droit).
- Limites d'usage : budgets quotidiens/mensuels par utilisateur et globaux, appliqués côté serveur
  avant chaque appel modèle.

## Journalisation et audit

`auth_events` (sécurité), `usage_log` (appels modèles : utilisateur, modèle, jetons, coût, latence),
`ingestion_runs` (contenu), `report_flags` (réponses signalées). Consultables dans l'admin.