# Revue de Sécurité - Afropreunariat

Ce document détaille une revue de sécurité complète de l'application Afropreunariat (basée sur Next.js, Prisma et PostgreSQL). Il identifie les menaces potentielles, les vulnérabilités courantes associées à cette pile technologique, et propose des solutions concrètes pour s'en prémunir.

---

## 1. Cross-Site Scripting (XSS)

**La menace :**
Le XSS survient lorsqu'un attaquant parvient à injecter du code JavaScript malveillant dans les pages web consultées par d'autres utilisateurs. Cela permet de voler des sessions, de rediriger les utilisateurs ou de modifier le contenu du site.

**Vulnérabilité identifiée sur le projet :**
L'application utilise massivement la propriété `dangerouslySetInnerHTML` pour afficher du contenu riche (articles de blog, événements, fiches entreprises, etc.) :
- `app/blog/[id]/page.tsx`
- `app/afrolife/[id]/page.tsx`
- `components/EventTimeline.tsx`
- `app/cgv/page.tsx`, `app/cgu/page.tsx`

Si le contenu inséré dans `dangerouslySetInnerHTML` provient des utilisateurs (via un éditeur WYSIWYG dans le panel admin par exemple) et n'est pas "nettoyé" (sanitized), un attaquant pourrait inclure une balise `<script>` malveillante.

**Comment corriger :**
- **Sanitisation :** Ne faites *jamais* confiance au contenu HTML en base de données. Utilisez une librairie de nettoyage (sanitizer) comme `isomorphic-dompurify` ou `dompurify` avant d'afficher le contenu.
  ```typescript
  import DOMPurify from 'isomorphic-dompurify';

  // Au lieu de :
  // <div dangerouslySetInnerHTML={{ __html: post.content }} />
  
  // Faites ceci :
  const cleanHTML = DOMPurify.sanitize(post.content);
  <div dangerouslySetInnerHTML={{ __html: cleanHTML }} />
  ```
- **CSP (Content Security Policy) :** Configurez des en-têtes CSP restrictifs dans `next.config.js` pour empêcher l'exécution de scripts non autorisés (inline scripts).

---

## 2. Injections SQL (SQLi)

**La menace :**
Un attaquant manipule les requêtes envoyées à la base de données en injectant du code SQL pour lire, modifier ou supprimer des données de manière non autorisée.

**État actuel du projet :**
L'utilisation de **Prisma ORM** protège nativement l'application contre les injections SQL grâce à l'utilisation de requêtes paramétrées en coulisse (ex: `prisma.event.findMany(...)`).

**Comment maintenir la sécurité :**
- Évitez d'utiliser les fonctions Prisma non sécurisées telles que `$queryRawUnsafe` ou `$executeRawUnsafe`.
- Si vous devez utiliser des requêtes brutes, utilisez TOUJOURS `$queryRaw` ou `$executeRaw` (sans le suffixe `Unsafe`), qui paramètrent automatiquement les variables grâce aux *tagged templates literals* (ex: `prisma.$queryRaw\`SELECT * FROM User WHERE id = ${id}\``).

---

## 3. Gestion de l'Authentification et des Sessions

**La menace :**
Le vol d'identifiants, l'usurpation d'identité ou la falsification de session.

**Vulnérabilité identifiée sur le projet :**
Le projet stocke apparemment l'utilisateur dans le stockage local du navigateur (`localStorage.getItem('afro_user')` dans `UserProvider.tsx`).
- Le `localStorage` est directement lisible par n'importe quel code JavaScript s'exécutant sur la page.
- Si une faille XSS est exploitée (voir point 1), l'attaquant peut lire le `localStorage` et voler la session de l'utilisateur (ou son token JWT s'il y est stocké).

**Comment corriger :**
- **Cookies HttpOnly :** Stockez les jetons d'authentification (JWT) ou les identifiants de session dans des cookies sécurisés (`HttpOnly`, `Secure`, `SameSite=Lax` ou `Strict`). Un cookie `HttpOnly` ne peut pas être lu par JavaScript, ce qui atténue grandement l'impact d'une faille XSS.
- Si NextAuth.js (Auth.js) n'est pas utilisé, envisagez de migrer vers ce standard qui gère nativement la sécurité des cookies.

---

## 4. Cross-Site Request Forgery (CSRF)

**La menace :**
Le CSRF force un utilisateur authentifié à exécuter des actions non désirées sur une application web dans laquelle il est actuellement authentifié (ex: suppression de compte, modification de mot de passe) via un lien malveillant ou un formulaire caché sur un autre site.

**Comment corriger :**
- **Server Actions :** Si vous utilisez les Server Actions de Next.js (`"use server"`), Next.js inclut une protection CSRF native (via la vérification des en-têtes `Origin` et `Host`).
- **API Routes (REST) :** Si vous utilisez des routes d'API (`app/api/...`) modifiant des données (POST, PUT, DELETE), assurez-vous que les cookies de session utilisent l'attribut `SameSite: 'Lax'` ou `SameSite: 'Strict'`. Cela empêche le navigateur d'envoyer le cookie si la requête provient d'un autre domaine.

---

## 5. Contrôle d'Accès et Autorisations (Broken Access Control)

**La menace :**
Un utilisateur accède à des ressources ou exécute des actions qu'il n'est pas censé pouvoir faire (ex: un utilisateur normal modifiant les réglages du site, ou accédant aux données d'une autre entreprise). On parle d'IDOR (Insecure Direct Object Reference).

**Comment corriger :**
- **Vérification systématique côté serveur :** Ne vous fiez jamais au front-end pour bloquer l'accès. Dans chaque Route API (`GET`, `POST`, `DELETE`) ou Action Serveur, vérifiez :
  1. Si l'utilisateur est authentifié.
  2. S'il a le bon rôle (ex: `user.role === 'ADMIN'`).
  3. Si la ressource manipulée lui appartient (ex: `business.ownerId === user.id`).
- *Exemple :* Si un utilisateur appelle `DELETE /api/businesses/123`, le serveur doit s'assurer que l'utilisateur qui fait la requête est le propriétaire de la boutique `123` ou un administrateur.

---

## 6. Attaques par Déni de Service (DDoS) et Brute Force

**La menace :**
Un attaquant submerge le serveur de requêtes pour le rendre indisponible, ou tente de deviner des mots de passe en envoyant des milliers de requêtes de connexion à la seconde.

**Comment corriger :**
- **Rate Limiting (Limitation de débit) :** Implémentez un Rate Limiter pour bloquer les IP abusives.
  - Utilisez un middleware de limitation (ex: `@upstash/ratelimit` avec Redis si déployé en serverless, ou un outil proxy inversé comme Nginx / Cloudflare).
- Pensez à limiter drastiquement les tentatives sur la route `/api/auth/login`.
- Mettez en place Cloudflare (ou équivalent) devant votre serveur pour absorber les attaques DDoS massives.

---

## 7. Exposition de Données Sensibles (Sensitive Data Exposure)

**La menace :**
Fuite de secrets (clés API, mots de passe de base de données) ou retour de trop d'informations aux clients (ex: renvoyer le mot de passe haché dans la réponse de l'API).

**Comment corriger :**
- **Fichier `.env` :** Assurez-vous que le fichier `.env` est bien dans le `.gitignore` et n'est jamais commité sur GitHub.
- **Select strict dans Prisma :** Lorsque vous récupérez un utilisateur, ne renvoyez jamais le mot de passe, même haché.
  ```typescript
  const user = await prisma.user.findUnique({
    where: { id: 1 },
    select: { id: true, name: true, email: true, role: true } // Ne sélectionnez PAS 'password'
  });
  ```

---

## 8. En-têtes de Sécurité HTTP

**La menace :**
Les navigateurs web disposent de mécanismes de sécurité natifs qui doivent être activés par le serveur via des en-têtes HTTP. S'ils sont absents, le site s'expose à des attaques comme le Clickjacking ou le reniflage de type MIME.

**Comment corriger :**
Ajoutez les en-têtes de sécurité dans votre fichier `next.config.js` :
```javascript
const securityHeaders = [
  { key: 'X-DNS-Prefetch-Control', value: 'on' },
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' }, // Force le HTTPS
  { key: 'X-XSS-Protection', value: '1; mode=block' },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' }, // Empêche le Clickjacking (le site ne peut pas être mis dans une iframe tierce)
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'origin-when-cross-origin' },
];

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ];
  },
};
```

---

## Résumé et Priorités d'Action

Pour sécuriser Afropreunariat de manière robuste, voici le plan d'action par ordre de priorité :

1. **🔴 Critique : Sécuriser les XSS.** Installez `dompurify` et nettoyez systématiquement toutes les variables passées dans `dangerouslySetInnerHTML`.
2. **🔴 Critique : Sécuriser la session.** Ne stockez plus les informations sensibles dans `localStorage`. Utilisez des cookies HttpOnly ou passez sur une librairie comme NextAuth.js.
3. **🟠 Haute : Valider les autorisations (IDOR).** Passez en revue les Server Actions et API Routes (suppression d'entreprise, modification d'articles) pour s'assurer qu'elles vérifient l'identité et les permissions de l'utilisateur.
4. **🟡 Moyenne : Configurer `next.config.js`.** Ajoutez les en-têtes de sécurité (Headers HTTP).
5. **🟡 Moyenne : Rate Limiting.** Protégez vos routes d'authentification contre le brute force.