Ce document détaille les mesures de sécurité implémentées pour protéger l'application Job Aggregator et ses données, conformément aux exigences du projet.

Voici le chemin parcouru par une requête utilisateur avant d'atteindre les données.

sequenceDiagram
    participant U as Utilisateur
    participant S as SWAG (Nginx/Fail2ban)
    participant A as Backend API (Go)
    participant M as Middleware Auth
    participant D as MariaDB

    U->>S: Requête HTTP/HTTPS
    Note over S: Vérification IP (Fail2ban)
    S->>A: Transmission vers le port 3000
    A->>M: Passage par middleware.Auth()
    alt Token Valide
        M->>A: Continue vers le Handler
        A->>D: Requête SQL (Préparée)
        D->>A: Données
        A->>U: Réponse 200 OK
    else Token Invalide / Absent
        M->>U: Erreur 401 Unauthorized
    end
    alt Tentatives répétées invalides
        S->>S: Bannissement IP via Fail2ban
    end

Nous utilisons l'image linuxserver/swag qui intègre fail2ban.

• Filtre personnalisé : Un filtre api_protect.conf surveille les logs pour détecter les patterns d'attaque.
• Action : En cas de détection (ex: 10 erreurs 401 en 1 minute), l'IP est bannie au niveau du firewall (iptables) du conteneur.

• Aucun secret n'est en dur dans le code.
• Utilisation de variables d'environnement (.env) chargées via Docker Compose.
• Le JWT_SECRET et les identifiants DB sont configurables à l'exécution.

Le système gère trois rôles : Admin (0), User (1), Company (2).

• Les routes sensibles (ex: /admin/*) sont protégées par le middleware Admin_Verif().
• Ce middleware vérifie le claim role extrait du token JWT après validation de la signature.

• Mots de passe : Hashés avec un salt unique par utilisateur (implémenté dans backend/routes/account/query/query.go).
• Transit : Chiffrement via TLS géré par le proxy inverse (SWAG).
• Validation : Centralisation de la validation des entrées via le framework Gin avant tout traitement métier.