Attaques
IDOR et contrôle d'accès
Une IDOR apparaît lorsqu'une application laisse accéder à une ressource en changeant simplement un identifiant, sans vérifier que l'utilisateur a réellement le droit d'y accéder.
Définition
IDOR signifie Insecure Direct Object Reference. Le problème n'est pas l'identifiant visible en lui-même, mais l'absence de contrôle d'accès côté serveur.
Exemple de ressource :
/factures/123
/factures/124
Si un utilisateur peut consulter la facture 124 alors qu'elle ne lui appartient pas, il y a probablement un problème de contrôle d'accès.
Pourquoi c'est fréquent
Les IDOR sont fréquentes parce que les applications manipulent constamment des identifiants :
- comptes
- factures
- commandes
- messages
- fichiers
- tickets support
- documents privés
L'interface peut cacher certains boutons, mais l'API ou le serveur doivent vérifier les droits à chaque action.
Authentification ne veut pas dire autorisation
Un utilisateur connecté n'a pas tous les droits.
| Situation | Question à vérifier |
|---|---|
| Lire une ressource | Appartient-elle à l'utilisateur |
| Modifier une ressource | A-t-il un droit d'écriture |
| Supprimer une ressource | L'action est-elle autorisée |
| Lister des données | Le filtre est-il appliqué côté serveur |
La règle doit être vérifiée côté serveur, pas seulement dans le front-end.
Signaux d'alerte
Pendant une revue ou un test autorisé, certains indices méritent attention :
- identifiants numériques simples
- endpoints qui prennent un
userId - absence de vérification propriétaire
- rôles gérés uniquement côté client
- réponses différentes selon l'identifiant
- exports ou téléchargements par ID direct
- messages d'erreur trop précis
Prévention
Bonnes pratiques :
- vérifier les droits côté serveur à chaque requête
- filtrer les données par utilisateur ou tenant
- centraliser les contrôles d'accès
- tester les rôles et permissions
- éviter de faire confiance aux champs
userIdenvoyés par le client - journaliser les accès refusés
- utiliser le moindre privilège côté base et API
L'utilisation d'UUID peut réduire la devinabilité, mais ne remplace jamais un contrôle d'accès.
À retenir
Un identifiant non devinable aide, mais la vraie protection reste la vérification d'autorisation côté serveur.
Tests défensifs utiles
Dans un cadre autorisé, il faut tester plusieurs profils :
- utilisateur A
- utilisateur B
- utilisateur non connecté
- compte avec droits limités
- compte admin
Les scénarios à vérifier :
- lecture d'une ressource d'un autre utilisateur
- modification d'une ressource d'un autre utilisateur
- suppression non autorisée
- export ou téléchargement non autorisé
- accès à une ressource après changement de rôle
Logs utiles
À journaliser :
- accès refusés
- accès à des ressources sensibles
- changements de rôle
- téléchargements de documents
- exports massifs
- tentatives répétées sur plusieurs identifiants
Ces logs peuvent révéler une tentative d'énumération ou un abus de droits.