Ingenieure en securite applicative
Comment tester les failles IDOR de votre application web en 7 etapes
TL;DR
- L'IDOR (Insecure Direct Object Reference) est la vulnerabilite #1 du Top 10 OWASP. Elle permet a un attaquant d'acceder aux donnees d'autres utilisateurs en modifiant un parametre dans l'URL.
- 7 etapes pour tester vos applications : cartographier les endpoints, identifier les references directes, tester avec deux comptes, automatiser avec Burp Suite, tester les methodes HTTP, verifier les reponses et documenter.
- Outils recommandes : Burp Suite, OWASP ZAP, Autorize (plugin Burp), Postman, cURL.
- Prevention : controles d'autorisation cote serveur, UUIDs au lieu d'IDs sequentiels, middleware d'autorisation systematique, rate limiting.
— Introduction : pourquoi tester les IDOR maintenant
L'affaire Belambra/Maeva/Gites de France de juin 2026 vient de rappeler brutalement que les failles IDOR restent l'une des vulnerabilites les plus dangereuses et les plus repandues dans les applications web. 5,3 millions de donnees personnelles exposees a cause d'une absence de controle d'autorisation — c'est le type d'incident qui detruit la reputation d'une entreprise et expose a des amendes RGPD colossales.
L'IDOR (Insecure Direct Object Reference) est classee dans la categorie A01:2021 - Broken Access Control du Top 10 OWASP, la vulnerabilite la plus repandue dans les applications web modernes. Selon les statistiques de l'OWASP, 94% des applications testees presentent au moins une forme de controle d'acces defaillant. Et pourtant, c'est l'une des failles les plus simples a detecter et a corriger.
Ce guide vous donne une methode concrete en 7 etapes pour tester vos applications web et detecter les failles IDOR avant qu'un attaquant ne le fasse a votre place. Que vous soyez developpeur, testeur QA, RSSI ou responsable technique, vous trouverez ici les outils et les techniques pour securiser vos applications.
— Etape 1 : Cartographier tous les endpoints de votre application
Avant de pouvoir tester quoi que ce soit, vous devez avoir une vue exhaustive de tous les endpoints de votre application qui manipulent des donnees utilisateur. C'est la phase de reconnaissance, et elle est fondamentale pour ne rien laisser passer.
Methode manuelle : naviguez dans votre application en utilisant un proxy intercepteur comme Burp Suite ou OWASP ZAP. Parcourez toutes les pages accessibles apres authentification : profil utilisateur, commandes, factures, messages, parametres, etc. Le proxy enregistrera automatiquement toutes les requetes HTTP emises, y compris les appels API en arriere-plan que vous ne voyez pas dans l'interface.
Methode automatisee : si votre application dispose d'une documentation API (Swagger/OpenAPI), importez-la directement dans Burp Suite ou Postman. Cela vous donnera la liste complete des endpoints disponibles. Sinon, utilisez le spider/crawler integre a votre outil de proxy pour decouvrir automatiquement les routes.
Ce que vous cherchez
/api/users/123, /orders/456
?user_id=123, ?invoice=789
{"userId": 123}
— Etape 2 : Identifier les references directes aux objets
Parmi tous les endpoints cartographies, concentrez-vous sur ceux qui utilisent des references directes pour acceder aux ressources. Les signes revelateurs d'un IDOR potentiel sont :
- •Identifiants numeriques sequentiels : si votre profil est accessible via
/user/1042, il est fort probable que/user/1041et/user/1043existent aussi. C'est le cas le plus critique. - •Noms de fichiers previsibles :
/documents/facture_2026_001.pdf— que se passe-t-il si vous changez le numero ? - •UUIDs dans les parametres : meme les UUIDs ne sont pas une protection suffisante si ils sont predictibles ou exposes dans d'autres parties de l'application (logs, emails, URLs partagees).
- •Identifiants dans les cookies ou headers : certaines applications passent des identifiants dans les cookies ou les headers HTTP personnalises, ce qui les rend moins visibles mais tout aussi vulnerables.
— Etape 3 : Creer deux comptes de test
Pour tester efficacement les IDOR, vous avez besoin de deux comptes utilisateur distincts sur votre application. Appelons-les Alice (compte A) et Bob (compte B). L'objectif est simple : en etant connecte avec le compte Alice, essayer d'acceder aux donnees de Bob en modifiant les identifiants dans les requetes.
Creez des donnees specifiques dans chaque compte pour pouvoir identifier clairement a qui appartiennent les donnees retournees : des commandes, des messages, des fichiers avec des noms distincts. Notez soigneusement les identifiants (IDs) des ressources de chaque compte.
Exemple pratique
# Compte Alice (A) - sa commande a l'ID 5001
GET /api/orders/5001
# Reponse : {order_id: 5001, customer: "Alice", total: 149.99}
# Maintenant, toujours connecte en tant qu'Alice :
GET /api/orders/5002 ← commande de Bob
# Si vous voyez les donnees de Bob = IDOR confirmee
— Etape 4 : Tester manuellement chaque endpoint
C'est le coeur du test. Pour chaque endpoint identifie a l'etape 2, effectuez la manipulation suivante en utilisant Burp Suite Repeater ou Postman :
-
a
Connectez-vous avec le compte Alice et capturez une requete vers une ressource d'Alice (ex: sa commande #5001).
-
b
Modifiez l'identifiant dans la requete pour pointer vers une ressource de Bob (#5002), en gardant le token de session d'Alice.
-
c
Analysez la reponse : si les donnees de Bob sont retournees avec un code HTTP 200, l'IDOR est confirmee. Si vous obtenez un 403 (Forbidden) ou un 404, le controle d'autorisation fonctionne.
-
d
Testez aussi l'inverse : connecte en tant que Bob, essayez d'acceder aux ressources d'Alice. Les controles doivent etre symetriques.
Attention aux faux negatifs : certaines applications renvoient un code 200 avec un body vide ou un message d'erreur au lieu d'un vrai code 403. Inspectez toujours le contenu de la reponse, pas seulement le code HTTP.
— Etape 5 : Automatiser avec Burp Suite et Autorize
Les tests manuels sont indispensables mais longs. Pour les applications avec des centaines d'endpoints, l'automatisation est necessaire. Le plugin Autorize pour Burp Suite est l'outil reference pour cette tache.
Autorize fonctionne en interceptant chaque requete emise par l'utilisateur A et en la rejouant automatiquement avec le token de session de l'utilisateur B. Il compare ensuite les reponses et signale celles qui sont identiques ou similaires, ce qui indique une absence de controle d'autorisation. Le resultat est un tableau clair avec un code couleur : vert (protege), rouge (IDOR) et orange (a verifier manuellement).
Configuration Autorize en 3 minutes
# 1. Installer Autorize via l'onglet Extender > BApp Store
# 2. Copier le cookie de session de l'utilisateur B
Cookie: session=eyJhbGciOiJ...tokenDeB
# 3. Coller dans Autorize > Configuration > Cookie header
# 4. Activer Autorize et naviguer normalement avec le compte A
# 5. Autorize teste automatiquement chaque requete avec le token B
— Etape 6 : Tester toutes les methodes HTTP
Une erreur frequente dans les tests IDOR est de ne tester que les requetes GET. Or, les IDOR les plus dangereuses sont souvent sur les methodes PUT, PATCH et DELETE, qui permettent non seulement de lire mais aussi de modifier ou supprimer les donnees d'autres utilisateurs.
Pour chaque endpoint identifie, testez systematiquement :
| Methode | Action | Impact IDOR | Exemple |
|---|---|---|---|
| GET | Lecture | Fuite de donnees | GET /api/users/42 |
| PUT | Modification | Modification de donnees | PUT /api/users/42 |
| PATCH | Modification partielle | Modification ciblee | PATCH /api/users/42 |
| DELETE | Suppression | Destruction de donnees | DELETE /api/users/42 |
| POST | Creation | Creation au nom d'autrui | POST /api/users/42/orders |
Un cas classique : l'endpoint GET /api/orders/123 est correctement protege (renvoie un 403 si ce n'est pas votre commande), mais DELETE /api/orders/123 ne l'est pas. Le developpeur a pense a proteger la lecture mais a oublie la suppression. Ce type d'inconsistance est extremement courant.
— Etape 7 : Documenter, corriger et retester
Pour chaque IDOR detectee, documentez soigneusement :
- •L'endpoint concerne : URL complete, methode HTTP, parametres
- •Les etapes de reproduction : requete exacte avec les headers et le corps
- •L'impact : quelles donnees sont accessibles, modifiables ou supprimables
- •La severite : basee sur le type de donnees et le volume potentiellement affecte
- •La correction recommandee : implementation specifique du controle d'autorisation
La correction type consiste a ajouter un controle cote serveur qui verifie que l'utilisateur authentifie est bien le proprietaire de la ressource demandee. En pseudo-code :
// AVANT (vulnerable)
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findById(req.params.id);
res.json(order);
});
// APRES (corrige)
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findById(req.params.id);
if (order.userId !== req.user.id) {
return res.status(403).json({ error: 'Forbidden' });
}
res.json(order);
});
Apres correction, retestez systematiquement chaque IDOR corrigee pour confirmer que le correctif est effectif. Ajoutez ces tests a votre suite de tests automatises (tests d'integration) pour eviter les regressions futures.
— Comparatif des outils de test IDOR
| Outil | Type | Prix | Ideal pour | Difficulte |
|---|---|---|---|---|
| Burp Suite Community | Proxy intercepteur | Gratuit | Tests manuels | Intermediaire |
| Burp Suite Pro + Autorize | Automatise | 449$/an | Tests a grande echelle | Intermediaire |
| OWASP ZAP | Proxy intercepteur | Gratuit (OSS) | Petites equipes | Debutant |
| Postman | Client API | Gratuit / Pro | APIs documentees | Debutant |
| cURL + scripts | CLI | Gratuit | Verification rapide | Avance |
Besoin d'un regard expert sur vos applications ?
Les tests IDOR font partie de chaque audit de securite applicative que nous realisons. Nos pentesteurs certifies OSCP et CEH identifient les failles que les outils automatises manquent. Premier audit gratuit.
Demander un audit de securite →— Bonnes pratiques de prevention
Detecter les IDOR c'est bien, les prevenir c'est mieux. Voici les mesures architecturales a mettre en place pour eliminer cette classe de vulnerabilites de maniere structurelle :
-
1
Middleware d'autorisation systematique
Implementez un middleware qui intercepte chaque requete et verifie que l'utilisateur authentifie est proprietaire de la ressource demandee. Ce middleware doit etre applique globalement, pas endpoint par endpoint, pour eviter les oublis.
-
2
UUIDs v4 au lieu d'identifiants sequentiels
Remplacez les IDs auto-incrementes (1, 2, 3) par des UUIDs v4 aleatoires. Cela ne remplace pas le controle d'autorisation mais rend l'enumeration beaucoup plus difficile. Un UUID v4 a 2^122 valeurs possibles — impossible a deviner.
-
3
Filtrage implicite par proprietaire
Plutot que de chercher une ressource par ID puis verifier le proprietaire, filtrez directement les requetes par l'utilisateur courant :
Order.find({userId: currentUser.id, _id: orderId}). Si la commande n'appartient pas a l'utilisateur, elle n'est tout simplement pas trouvee. -
4
Tests automatises dans la CI/CD
Ajoutez des tests d'integration qui verifient specifiquement les controles d'autorisation. Pour chaque endpoint, un test doit valider qu'un utilisateur ne peut pas acceder aux ressources d'un autre. Ces tests doivent s'executer a chaque commit pour prevenir les regressions. Consultez notre page services pour en savoir plus.
— Conclusion
Tester les failles IDOR n'est ni complexe ni couteux. Avec deux comptes de test, un proxy intercepteur gratuit et la methodologie en 7 etapes decrite dans ce guide, n'importe quel developpeur ou testeur peut identifier les vulnerabilites IDOR de son application en quelques heures. L'investissement en temps est derisoire compare aux consequences d'une exploitation : fuite massive de donnees, amendes RGPD, perte de confiance des clients.
L'affaire Belambra/Maeva/Gites de France de juin 2026 doit servir de catalyseur. Si trois acteurs majeurs du tourisme francais ont pu etre compromis par une faille aussi basique, combien d'autres applications sont assises sur la meme bombe ? La reponse est : beaucoup trop. Ne soyez pas la prochaine victime. Lancez vos tests IDOR des aujourd'hui, et si vous avez besoin d'aide, nos experts pentest sont la pour vous accompagner.
Vous preferez confier le test a des experts ?
Les pentesteurs WebGuard Agency realisent des audits IDOR complets sur vos applications web et APIs. Rapport detaille, plan de remediation et retest inclus. Premier audit gratuit.
Contactez nos experts →Pour aller plus loin
Questions frequentes
Vous ne trouvez pas la reponse a votre question ?
Veille cybersecurite
Recevez chaque semaine les dernieres menaces, vulnerabilites et bonnes pratiques directement dans votre boite mail.
Pas de spam. Desinscription en un clic. Environ 1 email par semaine.
— Pret a renforcer votre cybersecurite ?
Rejoignez les entreprises qui font confiance a WebGuard Agency pour proteger leurs actifs numeriques. Premier audit offert.