Comment tester les vulnerabilites IDOR de votre application web en 7 etapes

En avril 2026, une vulnerabilite IDOR sur le portail de l ANTS a expose 19 millions de profils citoyens. La faille etait triviale : changer un numero dans l URL de l API permettait d acceder au profil de n importe quel citoyen. Aucun controle d acces cote serveur. Aucun test de securite avant la mise en production.

Si une agence gouvernementale gerant les passeports et cartes d identite de la Republique peut etre compromise par la faille la plus elementaire du Top 10 OWASP, vos applications web sont-elles reellement protegees ? Ce guide vous donne une methodologie structuree en 7 etapes pour tester systematiquement les vulnerabilites IDOR de vos applications d entreprise.

— Etape 1 : Cartographier tous les endpoints de votre application

Avant de tester quoi que ce soit, vous devez disposer d une carte complete de tous les endpoints de votre application web. Cette cartographie est le fondement de tout test IDOR efficace. Sans elle, vous risquez de passer a cote des endpoints les plus critiques.

Methode manuelle : navigation proxifiee. Configurez Burp Suite Professional ou OWASP ZAP comme proxy HTTP. Naviguez dans l application en utilisant toutes les fonctionnalites : creation de compte, modification de profil, consultation de commandes, telechargement de documents, gestion des parametres. L outil enregistrera automatiquement chaque requete HTTP et construira un arbre de l application (sitemap). Attention aux single-page applications (SPA) en React, Vue ou Angular : les requetes API sont souvent invisibles sans proxy.

Methode complementaire : analyse de la documentation API. Si votre application dispose d une documentation OpenAPI/Swagger (generalement accessible via /swagger.json, /api-docs ou /openapi.yaml), importez-la dans Postman ou Burp Suite. Cette documentation revele souvent des endpoints non utilises par l interface utilisateur mais toujours actifs cote serveur. Verifiez egalement les fichiers JavaScript front-end : les URL d API y sont frequemment hardcodees.

Livrables de l etape 1 : un inventaire complet des endpoints avec pour chacun : l URL, la methode HTTP (GET, POST, PUT, DELETE), les parametres attendus et le type de donnees retournees. Classez chaque endpoint par niveau de sensibilite : critique (donnees personnelles, financieres), eleve (donnees metier), moyen (donnees de configuration), faible (donnees publiques).

— Etape 2 : Identifier les references directes aux objets

Une fois votre cartographie terminee, passez en revue chaque endpoint pour identifier les references directes aux objets internes. Ce sont les parametres qui pointent vers des ressources specifiques dans la base de donnees.

Ou chercher les references directes :

• Dans les URL : /api/users/123, /api/orders/456, /api/invoices/789/download
• Dans les parametres de requete : /api/documents?id=42, /api/reports?user_id=1001
• Dans le corps des requetes POST/PUT : {"account_id": 5678, "amount": 100}
• Dans les en-tetes HTTP : X-User-Id: 999 (plus rare mais existe)
• Dans les cookies : user_role=admin ou account=base64encodedvalue

Types d identifiants a surveiller : les entiers sequentiels (1, 2, 3...) sont les plus dangereux car trivialement enumerables. Les UUID v4 sont plus surs mais ne dispensent pas d un controle d acces cote serveur — un UUID peut etre intercepte dans un log, un email ou un referrer. Les identifiants encodes en Base64 offrent une fausse securite : base64decode("MTIzNA==") = "1234". Les hashs MD5 ou SHA-1 d entiers sequentiels sont egalement facilement reversibles via des rainbow tables.

Livrables de l etape 2 : un tableau listant chaque reference directe identifiee, l endpoint concerne, le type d identifiant (entier, UUID, hash, encode), le type de ressource referncee (utilisateur, commande, facture, document) et le niveau de sensibilite. C est ce tableau qui guidera vos tests dans les etapes 3 a 5.

— Etape 3 : Creer les comptes de test multi-roles

Les tests IDOR necessitent au minimum deux comptes utilisateurs avec le meme role (pour les tests horizontaux) et un compte par niveau de privilege (pour les tests verticaux). La preparation des comptes est une etape critique souvent negligee.

Configuration minimale recommandee :

• Utilisateur A : compte standard avec des donnees de test (profil renseigne, commandes passees, documents uploades)
• Utilisateur B : second compte standard, role identique a A, avec ses propres donnees distinctes
• Utilisateur Manager : compte avec privileges de gestion (acces aux equipes, rapports, validation)
• Utilisateur Admin : compte administrateur avec acces complet
• Utilisateur non authentifie : requetes sans token ni session (test des endpoints non proteges)

Pour chaque compte, notez les identifiants des ressources creees. Par exemple : l utilisateur A possede le profil ID 101, les commandes ID 501 et 502, le document ID 801. L utilisateur B possede le profil ID 102, la commande ID 503, le document ID 802. Ces identifiants seront croises dans les etapes suivantes.

Astuce pour les environnements de production : si vous testez sur un environnement de production (deconseille mais parfois impose), utilisez des comptes de test dedies avec des donnees fictives, et limitez vos tests aux operations de lecture (GET). Les tests en ecriture (PUT, POST, DELETE) doivent imperativement etre realises sur un environnement de staging ou de pre-production.

— Etape 4 : Executer les tests horizontaux (meme niveau de privilege)

Les tests horizontaux verifient qu un utilisateur ne peut pas acceder aux ressources d un autre utilisateur ayant le meme role. C est le scenario exact de la faille ANTS : un citoyen accedant au profil d un autre citoyen.

Procedure de test systematique :

1. Connectez-vous en tant qu Utilisateur A. Capturez les requetes HTTP vers les endpoints identifies a l etape 2.
2. Pour chaque requete contenant une reference directe, remplacez l identifiant de A par celui de B. Exemple : remplacez GET /api/users/101 par GET /api/users/102.
3. Envoyez la requete modifiee avec le token d authentification de A.
4. Analysez la reponse. Si le serveur retourne les donnees de l Utilisateur B, vous avez un IDOR.
5. Repetez pour chaque type de ressource : profils, commandes, documents, messages, factures, etc.
6. Testez egalement les operations d ecriture : PUT /api/users/102 avec le token de A pour tenter de modifier le profil de B.
7. Testez les operations de suppression : DELETE /api/orders/503 avec le token de A pour tenter de supprimer une commande de B.

Avec Burp Suite et l extension Autorize : l extension Autorize automatise ce processus. Configurez-la avec le cookie de session de l Utilisateur B. Naviguez dans l application en tant qu Utilisateur A. Autorize rejoue automatiquement chaque requete avec les credentials de B et compare les reponses. Les endpoints ou les deux utilisateurs recoivent les memes donnees sont marques en rouge : ce sont vos IDOR potentiels.

Resultats attendus : pour chaque test, la reponse correcte est un code HTTP 403 Forbidden ou 404 Not Found. Si vous recevez un 200 OK avec les donnees de l autre utilisateur, c est un IDOR confirme. Documentez le endpoint, la requete, la reponse et le niveau de criticite.

— Etape 5 : Executer les tests verticaux (escalade de privileges)

Les tests verticaux verifient qu un utilisateur avec un role inferieur ne peut pas acceder aux ressources reservees a un role superieur. Un utilisateur standard ne doit pas pouvoir acceder aux endpoints d administration. Un manager ne doit pas pouvoir acceder aux fonctions de super-administrateur.

Scenarios de test verticaux prioritaires :

• Utilisateur standard vers Admin : tentez d acceder aux endpoints d administration (/api/admin/users, /api/admin/config, /api/admin/logs) avec un token utilisateur standard.
• Utilisateur standard vers Manager : tentez d acceder aux endpoints de gestion d equipe, de validation, de reporting.
• Utilisateur non authentifie vers Utilisateur standard : tentez d acceder aux endpoints proteges sans aucun token d authentification.
• Modification de role dans le token : si le role est encode dans un JWT ou un cookie, tentez de le modifier (de "role":"user" a "role":"admin"). Si le serveur accepte le token modifie, la faille est critique.

Tests sur les fonctions sensibles : concentrez-vous sur les endpoints permettant de modifier les privileges (changement de role, ajout d un utilisateur a un groupe admin), d exporter des donnees en masse (export CSV, rapports globaux), de modifier la configuration de l application (parametres de securite, politiques de mot de passe) ou de supprimer des ressources critiques (comptes utilisateurs, donnees clients).

— Etape 6 : Automatiser les tests recurrents

Les tests manuels des etapes 4 et 5 sont essentiels pour la decouverte initiale, mais ils ne scalent pas. Pour une protection continue, integrez les tests IDOR dans votre pipeline CI/CD et vos processus de deploiement.

Avec OWASP ZAP en mode headless : OWASP ZAP peut s executer en ligne de commande et s integrer dans un pipeline Jenkins, GitLab CI ou GitHub Actions. Configurez un scan d API en fournissant votre fichier OpenAPI. ZAP testera automatiquement les endpoints pour les problemes de controle d acces de base, y compris les IDOR sur les identifiants sequentiels.

Avec Nuclei et des templates personnalises : Nuclei de ProjectDiscovery permet de creer des templates YAML specifiques a vos applications. Ecrivez un template qui authentifie un utilisateur A, recupere l identifiant d une ressource, puis tente d y acceder avec les credentials de l utilisateur B. Le template peut etre execute a chaque deploiement via votre pipeline.

Avec Postman/Newman : creez une collection Postman avec des tests de controle d acces pour chaque endpoint critique. Utilisez les variables d environnement pour alterner entre les tokens d authentification. Executez la collection avec Newman dans votre pipeline CI/CD. Chaque test doit verifier que la reponse est bien un 403 ou 404 lorsque le token ne correspond pas au proprietaire de la ressource.

Limites de l automatisation : les IDOR complexes impliquant une logique metier specifique (acces indirect via des relations d objets, IDOR sur des workflows multi-etapes, IDOR bases sur le contexte temporel) echappent souvent aux tests automatises. Prevoyez un test de penetration manuel au minimum une fois par an, et a chaque modification majeure de l application. Notre guide sur l audit de securite et sa methodologie detaille le cadre complet.

— Etape 7 : Documenter, prioriser et remedier

La documentation est souvent negligee, mais elle est cruciale pour la conformite reglementaire (NIS2, RGPD) et pour la priorisation des remediations. Un rapport IDOR bien structure facilite la prise de decision par la direction et accelere la correction par les equipes de developpement.

Structure du rapport IDOR :

• Pour chaque IDOR identifie : endpoint concerne, type de test (horizontal/vertical), requete de preuve (avec les donnees sensibles masquees), reponse du serveur, impact metier (quelles donnees sont exposees, a qui), score CVSS estime.
• Classification par criticite : Critique (donnees personnelles ou financieres, acces admin), Elevee (donnees metier sensibles), Moyenne (donnees internes non sensibles), Faible (donnees a impact limite).
• Remediation recommandee pour chaque IDOR : implementation d un controle d acces cote serveur (middleware d autorisation), remplacement des identifiants sequentiels par des UUID v4, ajout de logging et d alerting sur les tentatives d acces non autorises.

Priorisation de la remediation : les IDOR critiques (donnees personnelles, acces admin) doivent etre corriges dans les 48 heures. Les IDOR eleves dans la semaine. Les IDOR moyens dans le sprint suivant. Les IDOR faibles dans le prochain cycle de maintenance. Pour les entites soumises a NIS2, les IDOR critiques et eleves sur des services essentiels doivent etre reportes a l ANSSI s ils ont ete exploites.

Les patterns de correction les plus efficaces :

• Middleware d autorisation centralise : implementez un middleware qui verifie systematiquement que l utilisateur authentifie est autorise a acceder a la ressource demandee. En Python/Django : get_object_or_404(Model, pk=pk, owner=request.user). En Node.js/Express : un middleware qui extrait le user_id du token JWT et le compare au proprietaire de la ressource.
• Controle au niveau de la requete de base de donnees : ajoutez un filtre WHERE owner_id = :current_user_id a toutes les requetes SELECT, UPDATE et DELETE. Si la requete retourne zero resultat, retournez un 404.
• Identifiants non predictibles : remplacez les entiers sequentiels par des UUID v4 pour toutes les ressources exposees via API. Cela n elimine pas le besoin d un controle d acces mais ajoute une couche de defense en profondeur.

Pour un cadre complet de conformite, notre analyse de l hygiene informatique selon l ANSSI detaille les mesures de base que toute organisation doit implementer, y compris les controles d acces applicatifs.

— Erreurs courantes a eviter

Au fil de nos audits, nous observons des erreurs recurrentes qui laissent des IDOR en production malgre des tests de securite. Voici les pieges les plus frequents.

Tester uniquement les endpoints documentes. Les API ont souvent des endpoints non documentes, des endpoints de debug laisses en production, ou des anciennes versions d API toujours actives (/api/v1/users vs /api/v2/users). Les anciens endpoints peuvent avoir des controles d acces moins stricts. Utilisez des outils de fuzzing (ffuf, dirsearch) pour decouvrir les endpoints caches.

Confondre UUID et securite. L utilisation d UUID v4 rend l enumeration impraticable, mais ne constitue pas un controle d acces. Un UUID peut fuiter dans un log, un email de notification, un webhook, un referrer HTTP ou un export CSV. Si un attaquant obtient un UUID valide par un canal secondaire, l absence de controle d acces cote serveur lui donne acces a la ressource. L UUID est une mesure de defense en profondeur, pas un substitut au controle d acces.

Oublier les IDOR indirects. Un IDOR indirect se produit quand l acces a une ressource passe par une relation d objet. Exemple : vous ne pouvez pas acceder directement au profil de l Utilisateur B via /api/users/102, mais vous pouvez acceder a ses commandes via /api/orders/503, et la reponse de la commande contient le profil complet du proprietaire. Testez les chaines de relations, pas seulement les acces directs.

Ne pas tester les methodes HTTP alternatives. Un endpoint peut bloquer l acces via GET mais l autoriser via POST, PUT ou PATCH. Testez toutes les methodes HTTP sur chaque endpoint sensible. Certaines applications autorisent egalement l override de methode via l en-tete X-HTTP-Method-Override.

— FAQ