IDOR : comprendre cette faille d’accès

Auteur : Rédaction Domeny.ForSale Publié le 20.10.2026

En bref : IDOR (Insecure Direct Object Reference) est une faille qui permet d’accéder à une ressource appartenant à autrui en indiquant son identifiant, sans vérification adéquate des droits d’accès. Par exemple, un utilisateur modifie le numéro de facture dans l’adresse et voit le document d’un autre client. Le problème n’est pas le numéro dans l’adresse, mais l’absence de vérification, par le serveur, du droit de cette personne à accéder à la facture.

Comment fonctionne IDOR : un exemple simple

Imaginez un espace client dans lequel vous téléchargez votre facture après vous être connecté. Le navigateur envoie au serveur une requête pour le chemin /factures/481, et l’application renvoie le document numéro 481.

Une telle adresse n’a rien d’anormal en soi. La faille apparaît si le fait de remplacer ce chemin par /factures/482 permet de télécharger la facture d’un autre client, alors que vous n’avez pas reçu l’autorisation d’y accéder.

C’est comme un vestiaire où l’employé remettrait un manteau à toute personne donnant un numéro de cintre, sans vérifier qu’elle a le droit de le récupérer. Le numéro désigne l’objet, mais ne prouve pas que la personne est autorisée à le recevoir.

Dans IDOR, le mot « objet » désigne une ressource de l’application : un document, une commande, une photo, un message ou un compte. La « référence directe » consiste à désigner cette ressource par son identifiant. Celui-ci n’est pas nécessairement un numéro séquentiel : il peut s’agir d’un nom de fichier, d’une adresse e-mail ou d’une longue chaîne de caractères.

Pourquoi se connecter ne suffit pas

L’authentification répond à la question : « Qui êtes-vous ? » L’autorisation, c’est-à-dire la vérification des droits, répond à une autre question : « Que pouvez-vous faire ? » Une application peut reconnaître correctement l’utilisateur connecté tout en lui donnant accès aux données d’autrui.

Un serveur sécurisé doit vérifier non seulement que la facture existe, mais aussi que l’utilisateur a le droit de la consulter. Ce droit d’accès peut découler du fait que le document lui appartient, de son rôle dans l’organisation ou d’un partage volontaire du document avec cette personne.

IDOR ne se limite pas à la consultation d’informations. L’absence de contrôle peut aussi permettre de modifier ou de supprimer une ressource appartenant à autrui, par exemple l’adresse de livraison d’une commande. Le droit de lecture n’implique pas automatiquement le droit de modification : chaque opération nécessite donc un contrôle adapté.

Si l’application est utilisée par plusieurs entreprises, la séparation entre les organisations est également importante. L’administrateur d’une entreprise ne doit pas pouvoir accéder aux données d’une autre simplement parce qu’il connaît l’identifiant d’un de ses documents.

Où peut se trouver l’identifiant à l’origine de la faille ?

L’identifiant n’est pas forcément visible dans la barre d’adresse. Il peut se trouver dans les paramètres de requête, dans le corps d’une requête envoyée par un formulaire ou dans un appel à une API, c’est-à-dire une interface permettant à des programmes de communiquer entre eux.

Les opérations qui nécessitent généralement un contrôle sont :

le téléchargement de factures, de pièces jointes et d’exports de données ;
la consultation de messages, de demandes d’assistance et de commandes ;
la mise à jour du profil ou des paramètres du compte ;
la suppression de fichiers et d’autres ressources.

Tout accès obtenu après avoir changé un identifiant ne constitue pas une erreur. Un billet de blog public doit être accessible à tous, et un document partagé doit l’être aux collaborateurs autorisés. Ce qui caractérise la faille, c’est le non-respect des règles d’accès prévues, et non la simple possibilité de désigner un autre objet.

Dans les API, des erreurs similaires sont parfois désignées par le terme BOLA (Broken Object Level Authorization), qui correspond à un contrôle défaillant des droits au niveau d’un objet précis. Ces notions sont étroitement liées ; la question pratique reste la même : le serveur vérifie-t-il que l’utilisateur a le droit d’accéder à la ressource indiquée et d’effectuer l’action demandée ?

Ce qui protège réellement contre IDOR

La protection essentielle consiste à vérifier les droits côté serveur à chaque accès à une ressource. Masquer un bouton dans l’interface ne suffit pas, car il est possible d’envoyer la requête sans utiliser ce bouton.

Dans l’exemple des factures, l’application doit rechercher le document parmi ceux auxquels l’utilisateur a accès, ou vérifier ses droits avant de le renvoyer. Elle ne doit pas considérer le champ « propriétaire » transmis par le navigateur comme une preuve de propriété.

Les identifiants aléatoires, tels que les UUID, rendent les adresses plus difficiles à deviner, mais ne remplacent pas le contrôle des autorisations. Si un identifiant est divulgué, par exemple dans un lien partagé, le serveur doit toujours refuser l’accès aux personnes non autorisées.

Une bonne règle consiste à refuser par défaut : si l’application ne peut pas confirmer le droit d’effectuer une opération, elle ne l’exécute pas. Le contrôle doit aussi couvrir les téléchargements de fichiers et les exports, pas seulement l’écran principal du document.

Comment tester votre propre application en toute sécurité

Effectuez ce type de test uniquement sur un système qui vous appartient ou que vous êtes autorisé à tester. Il est préférable d’utiliser un environnement de test et des données fictives, en particulier pour les opérations de modification et de suppression.

Créez deux comptes de test, A et B, sans ressources partagées entre eux.
Depuis le compte A, créez un document et notez son identifiant.
Connectez-vous avec le compte B et essayez de consulter ce document par l’interface prévue ou par la API.
Testez séparément les possibilités de modification, de téléchargement et de suppression, si ces actions existent.
Vérifiez non seulement le message de refus, mais aussi qu’aucune donnée n’a été divulguée ou modifiée.

Le serveur doit refuser l’opération non autorisée ; il peut aussi choisir de ne pas révéler si le document existe. Il est utile d’ajouter ce scénario aux tests automatisés afin qu’une modification du code ne réintroduise pas la faille.

À lire aussi : Qu’est-ce que le 2FA ?