Contrôle d'accès : comment éviter qu'un utilisateur accède aux données d'un autre ?

Question

Un testeur a changé l'ID dans l'URL `/api/factures/1042` en `/api/factures/1043` et a vu la facture d'un autre client. L'utilisateur était bien connecté. Comment corriger proprement ?

Accepted Answer

C'est une faille **IDOR** (*Insecure Direct Object Reference*), classée n°1 du Top 10 OWASP (« Broken Access Control »). Être **authentifié** ne veut pas dire être **autorisé** à accéder à *cette* ressource.

**Correction** : chaque requête doit vérifier que la ressource appartient à l'utilisateur (ou qu'il a un rôle qui l'autorise). Le plus sûr est d'intégrer la vérification **dans la requête** :

```ts
const facture = await db.facture.findFirst({
  where: { id: params.id, clientId: session.user.clientId },
});
if (!facture) return notFound(); // 404 plutôt que 403 : ne révèle pas l'existence
```

**Pour que ça ne se reproduise pas :**
1. **Centralise** l'autorisation (fonctions `canViewInvoice(user, invoice)`, politiques) au lieu de la réécrire partout.
2. **Refus par défaut** : une nouvelle route sans vérification explicite ne doit rien retourner.
3. **Tests automatisés** : pour chaque endpoint, un test « l'utilisateur B ne peut pas lire, modifier ni supprimer la ressource de A ».
4. Pour du multi-tenant avec PostgreSQL, la **Row Level Security** ajoute un filet de sécurité au niveau de la base.

Des IDs non devinables (UUID) réduisent l'exploitation, mais **ne remplacent pas** la vérification.

1 Repons