# Conventions de sécurité Web

## But

Cette page résume les mécanismes de sécurité réellement présents dans le projet. Elle ne remplace pas un audit de sécurité; elle sert de guide pour éviter de contourner les protections existantes lorsqu’on ajoute une feature.

## Authentification et autorisation

Le backend utilise des JWT et plusieurs guards spécialisés :

- `AuthGuardUser` : utilisateur authentifié;
- `AuthGuardAdmin` : rôle admin;
- `AuthGuardAdminUser` : admin ou admin\_user;
- `AuthGuardGame` : accès utilisé par les appels du jeu.

Les tokens peuvent être lus depuis l’en-tête `Authorization: Bearer ...` ou, selon le flux, depuis le cookie `token`. Les guards backend restent la source d’autorité; les guards Angular servent surtout à contrôler la navigation.

## Flux d’autorisation

```mermaid
sequenceDiagram
    participant C as Client
    participant G as Guard NestJS
    participant J as JwtService
    participant E as Endpoint

    C->>G: Requête + token
    G->>J: Vérifie signature / expiration
    J-->>G: Payload
    G->>G: Vérifie rôle si nécessaire
    alt Autorisé
        G->>E: Continue
        E-->>C: Réponse
    else Refusé
        G-->>C: 401 Unauthorized
    end

```

## Configuration HTTP

Dans `src/main.ts` :

- CORS est configuré avec credentials;
- les requêtes JSON et URL-encoded ont une limite de taille;
- l’en-tête HSTS `Strict-Transport-Security` est ajouté;
- le serveur principal écoute sur le port `3000`.

## Uploads du support

`SupportAttachmentService` applique plusieurs contrôles avant de stocker ou servir une image :

- validation du contenu binaire réel plutôt que confiance dans le MIME envoyé par le navigateur;
- types d’image autorisés limités;
- normalisation en WebP;
- limite de dimensions et de taille;
- nom de fichier aléatoire et normalisé;
- protection contre les chemins arbitraires via `path.basename` et validation du format;
- vérification que la pièce jointe appartient à la conversation/utilisateur demandé;
- quotas de stockage utilisateur et global;
- nettoyage des uploads orphelins.

## Sécurité des fichiers

```mermaid
flowchart TD
    U[Upload] --> BIN[Valider signature binaire]
    BIN --> SIZE[Vérifier dimensions / taille]
    SIZE --> NORMAL[Normaliser en WebP]
    NORMAL --> NAME[Générer nom aléatoire]
    NAME --> QUOTA[Vérifier quotas]
    QUOTA --> SAVE[Écrire avec création exclusive]

    READ[Lecture] --> PATH[Vérifier nom / chemin]
    PATH --> OWNER[Vérifier conversation + utilisateur]
    OWNER --> FILE[Servir le fichier]

```

## Secrets et configuration

Le projet contient encore des secrets historiques dans la configuration. Ils ne doivent **jamais** être copiés dans le wiki, le frontend ou les logs. Toute nouvelle intégration devrait préférer les fichiers d’environnement ou une gestion de secrets dédiée plutôt qu’ajouter une nouvelle clé en clair dans le code.

## IA et contrôle d’usage

Le système IA possède des limites de requêtes, budgets, timeouts et plafonds de tokens configurés dans `AI_CONFIG`. Le dossier `src/node.js/server/ai/guard/` contient également la logique de garde liée aux coûts.

## Checklist pour une nouvelle route

- Choisir le guard backend correspondant au niveau d’accès.
- Ne jamais se fier uniquement à l’UI ou au routing Angular.
- Valider les IDs liés à l’utilisateur côté serveur.
- Limiter et valider les entrées volumineuses ou fichiers.
- Ne pas exposer de secret dans une réponse API ou dans Angular.
- Préférer une erreur contrôlée à une exception brute contenant des détails internes.
- Vérifier les permissions avant de lire un fichier ou une ressource appartenant à un autre utilisateur.