IDOR : quand changer un chiffre dans l’URL suffit

Le principe

Beaucoup d’applications identifient vos données par un numéro : app.exemple.fr/facture?id=1042. Le problème apparaît quand le site vérifie SEULEMENT que vous êtes connecté, mais jamais que la facture n°1042 vous appartient vraiment.

Changez ce nombre pour 1043, et si rien ne vous en empêche côté serveur, vous lisez la facture d’un inconnu. Aucune compétence technique requise : juste savoir modifier un chiffre dans une barre d’adresse.

Un exemple concret

Espace client d’une boutique en ligne : /mon-compte/commande/8821. En changeant l’URL en /mon-compte/commande/8822, un client malveillant peut consulter la commande, l’adresse postale et parfois les derniers chiffres de carte d’un autre client — sans rien pirater, juste en changeant un chiffre.

Le même principe s’applique à une API : GET /api/users/118/profile répond avec le profil de l’utilisateur 118, quel que soit le compte réellement connecté. C’est encore plus fréquent sur les API, où personne ne « voit » l’URL défiler dans un navigateur.

Pourquoi c’est grave

IDOR (Insecure Direct Object Reference) figure dans le Top 10 OWASP sous A01:2021 – Contrôle d’accès défaillant, la catégorie n°1 en fréquence ces dernières années. Contrairement à une injection SQL, elle ne demande aucune compétence d’attaquant particulière.

C’est souvent la faille la plus simple à trouver ET la plus dévastatrice : un identifiant qui s’incrémente permet d’aspirer les données de TOUS les comptes un par un, une simple boucle suffit. Fuite de données personnelles en masse, exposition RGPD directe.

Comment s’en protéger

Ne jamais faire confiance à un identifiant fourni par le visiteur sans vérifier qu’il lui appartient. Sur CHAQUE accès à une ressource, ajouter systématiquement la vérification côté serveur : « cette commande appartient-elle bien à l’utilisateur actuellement connecté ? »

Préférer des identifiants non devinables (UUID) aux compteurs séquentiels (1, 2, 3…) en complément — mais ça ne remplace jamais le contrôle d’accès, ça le rend seulement plus difficile à deviner par hasard. Le vrai correctif reste la vérification de propriété, pas l’obscurité de l’identifiant.

Comment SauronSec la détecte

Le signal le plus fort : deux comptes de test réels et distincts sont utilisés, et SauronSec vérifie si les données du premier sont lisibles avec la session du second. C’est la preuve qui ne ment jamais — un simple refus d’accès anonyme ne suffit pas à conclure à une faille.

Un identifiant « nonsense » sert de témoin de contrôle : si une page statique répond de la même façon qu’un vrai identifiant inexistant, ce n’est pas une faille, c’est une 404 déguisée. Sans ce témoin, un scanner naïf signale des centaines de faux IDOR sur du contenu simplement public.