• Contact

Failles IDOR

  • Mise à jour le 4 juin 2026
  • 1 min. à lire

Les failles IDOR (Insecure Direct Object Reference, ou référence directe non sécurisée à un objet) constituent une vulnérabilité de contrôle d'accès : une application expose une référence directe vers un objet interne (identifiant en base de données, nom de fichier, clé) sans vérifier que l'utilisateur est autorisé à y accéder. En manipulant simplement cette référence, un attaquant peut consulter ou modifier des données appartenant à d'autres utilisateurs.

Cette faille appartient à la catégorie A01:2021 – Broken Access Control du Top 10 de l'OWASP, aujourd'hui la classe de vulnérabilité web la plus répandue.

Exemple concret

Une application affiche une facture via l'URL :

https://exemple.fr/factures?id=1024

Si le serveur renvoie la facture sans vérifier qu'elle appartient bien à l'utilisateur connecté, il suffit de remplacer 1024 par 1025 pour accéder à la facture d'un autre client. Le même principe s'applique aux identifiants présents dans les corps de requête, les cookies ou les API REST (/api/users/1025/profile).

Code vulnérable vs sécurisé

# Vulnerable : aucune verification de propriete
@app.route("/factures")
def get_facture():
    facture_id = request.args.get("id")
    return db.get_facture(facture_id)

# Securise : on verifie que la facture appartient a l'utilisateur
@app.route("/factures")
def get_facture():
    facture_id = request.args.get("id")
    facture = db.get_facture(facture_id)
    if facture.owner_id != current_user.id:
        abort(403)  # Acces refuse
    return facture

La règle d'or : ne jamais faire confiance à un identifiant fourni par le client sans contrôle d'autorisation côté serveur.

Comment s'en protéger

  1. Contrôle d'accès systématique : vérifier, à chaque requête, que l'utilisateur authentifié a bien le droit d'accéder à la ressource demandée.
  2. Références indirectes : préférer des identifiants imprévisibles (UUID, jetons aléatoires) aux entiers séquentiels. Cela complique l'énumération, mais ne remplace jamais le contrôle d'accès.
  3. Logique d'autorisation centralisée : éviter de dupliquer les vérifications dans chaque endpoint, source d'oublis.
  4. Tests automatisés : intégrer des scénarios d'accès horizontal (un utilisateur tente d'atteindre les données d'un autre) dans les tests de sécurité.

Les IDOR sont d'autant plus dangereuses qu'elles sont simples à exploiter et souvent invisibles dans les logs applicatifs classiques : la requête est techniquement valide, seul le contexte d'autorisation est en faute.

Termes connexes : Broken Access Control, OWASP Top 10, élévation de privilèges, authentification / autorisation, vulnérabilité.

tracking-thumb