Vulnérabilité IDOR : définition, exemples et prévention 2026

Une vulnérabilité IDOR (Insecure Direct Object Reference) est une faille de sécurité applicative où un programme expose côté client des identifiants d'objets internes (ID base de données, nom de fichier, clé de ressource) sans vérifier systématiquement que l'utilisateur authentifié a le droit d'accéder à l'objet référencé. Elle fait partie de la famille Broken Access Control, classée A01:2021 dans OWASP Top 10 (position n°1 des risques applicatifs depuis 2021) et API1:2023 BOLA dans OWASP API Security Top 10. Techniquement classifiée sous CWE-639 (Authorization Bypass Through User-Controlled Key), elle reste en 2026 la vulnérabilité la plus fréquemment rapportée en bug bounty et la plus impactante en fuite de données. Cet article détaille la définition précise, les trois types d'IDOR, les exemples concrets en code, les incidents majeurs, les méthodes de détection et les stratégies de prévention.

Qu'est-ce qu'une IDOR exactement

Une IDOR survient quand trois conditions sont réunies :

1. L'application expose côté client un identifiant qui référence un objet interne (un entier, une chaîne, un UUID, un nom de fichier).
2. Cet identifiant est manipulable par un utilisateur authentifié — typiquement dans une URL, un paramètre de requête, un corps JSON ou un en-tête.
3. Le serveur ne vérifie pas, ou vérifie incorrectement, que l'utilisateur authentifié a le droit d'accéder à cet objet spécifique.

Conséquence : un utilisateur authentifié mais non autorisé accède, modifie ou supprime des données qui appartiennent à un autre utilisateur ou à un autre périmètre (autre tenant, autre organisation, autre client).

Distinction importante avec les autres familles de vulnérabilités

Les trois types d'IDOR

La littérature OWASP distingue trois grands patterns d'IDOR, qui peuvent se combiner dans une même application.

IDOR horizontale

L'utilisateur authentifié accède à des ressources d'un autre utilisateur du même niveau de privilège. Exemple : le compte A accède aux commandes du compte B en modifiant /orders/123 en /orders/124. C'est le pattern le plus fréquent en bug bounty et le plus simple à démontrer.

IDOR verticale

L'utilisateur accède à des ressources normalement réservées à un rôle supérieur. Exemple : un utilisateur standard accède à /admin/users/456 ou exécute DELETE /api/tenant-settings/789 via manipulation d'ID, là où seul un administrateur devrait pouvoir le faire. Souvent combinée avec d'autres défauts (route admin accessible sans vérification de rôle).

IDOR à référence directe de fichier ou de ressource externe

L'identifiant est un nom de fichier, une clé S3, un chemin, une URL. Exemple : /download?file=invoice_2024_00123.pdf où l'utilisateur devine les noms des factures d'autres clients par incrémentation ou pattern.

Comment fonctionne une IDOR : mécanismes techniques

Le mécanisme type suit un scénario classique en 5 étapes.

1. Observation : l'attaquant identifie un endpoint qui manipule un objet via un identifiant (/api/users/:id, /documents/:docId).
2. Format identification : il analyse le format de l'ID (entier séquentiel, UUID, chaîne base64, hash, composite).
3. Manipulation : il substitue son ID par celui d'un autre utilisateur, soit via énumération (entiers séquentiels), soit via fuite (URLs partagées, logs, références externes).
4. Rejeu authentifié : il rejoue la requête avec ses propres cookies/tokens de session.
5. Validation : si la réponse HTTP 200 contient les données cibles, l'IDOR est confirmée.

// Exemple type : API Express vulnérable vs sécurisée
 
// INSECURE — aucun contrôle d'autorisation, IDOR triviale
app.get('/api/orders/:orderId', authenticate, async (req, res) => {
  const order = await db.orders.findById(req.params.orderId);
  if (!order) return res.status(404).json({ error: 'Not found' });
  return res.json(order);
});
 
// SECURE — contrôle d'autorisation au niveau objet
app.get('/api/orders/:orderId', authenticate, async (req, res) => {
  const order = await db.orders.findById(req.params.orderId);
  if (!order) return res.status(404).json({ error: 'Not found' });
 
  // Contrôle de propriété : utilisateur propriétaire OU admin autorisé
  const canAccess =
    order.userId === req.user.id ||
    req.user.roles.includes('admin:orders');
 
  if (!canAccess) {
    logger.warn('unauthorized order access attempt', {
      userId: req.user.id,
      targetOrderId: req.params.orderId,
    });
    // Retourner 404 et non 403 : éviter la fuite d'existence de l'objet
    return res.status(404).json({ error: 'Not found' });
  }
 
  return res.json(order);
});

IDOR vs BOLA : la version API

Avec la bascule massive vers les architectures API-first depuis 2018, l'OWASP a publié un référentiel dédié aux API (OWASP API Security Top 10). L'équivalent direct de l'IDOR y figure sous l'identifiant API1:2023 BOLA (Broken Object Level Authorization), position n°1 du Top 10 API depuis sa création.

La fréquence BOLA en API est significativement plus élevée qu'en web classique : selon Salt Security API Security Report 2024, 30 à 40 % des vulnérabilités critiques trouvées sur des API exposées sont des BOLA. La cause principale : la multiplicité des endpoints d'API modernes (50-500 endpoints par application moyenne) vs l'application web monolithique historique (20-50 endpoints), et la tentation du « chaque microservice gère son propre contrôle d'accès » qui multiplie les points de défaillance.

Classification OWASP, CWE et CVE notables

Référentiels de classification à connaître en 2026

CVE IDOR publiques notables (2019-2024)

• CVE-2019-5418 (Ruby on Rails) : Directory Traversal via ActionView, combinaison IDOR + path traversal.
• CVE-2020-11108 (Pi-hole) : IDOR dans l'interface admin permettant RCE.
• CVE-2021-44228 n'est pas une IDOR mais cohabite historiquement dans les rapports post-Log4Shell avec des chaînages IDOR pour compléter l'impact.
• CVE-2022-24637 (Open Web Analytics) : IDOR permettant la prise de contrôle admin.
• CVE-2023-37611 (WP Webhooks) : IDOR dans plugin WordPress très utilisé.

Impact business et incidents majeurs

L'impact d'une IDOR dépasse souvent la simple exposition technique. Quelques incidents publics emblématiques.

First American Financial Corp (2019) — Vulnérabilité IDOR dans l'application EagleProNetwork qui exposait 885 millions de documents financiers clients (titres de propriété, transactions hypothécaires, numéros de sécurité sociale) sur une simple manipulation d'ID numérique séquentiel dans l'URL. Amende SEC 487 000 USD en 2021 ; réforme complète du programme AppSec imposée.

T-Mobile (2018) — Vulnérabilité IDOR dans l'API du portail client exposant numéros de téléphone, e-mails, IMSI, numéros de compte de 2 millions d'utilisateurs via manipulation d'ID numérique.

USPS Informed Visibility (2018) — IDOR dans l'API de suivi postal exposant les données de 60 millions de comptes, découverte par un chercheur indépendant, correction en 12 mois.

Parler (janvier 2021) — Extraction massive de posts utilisateurs via IDOR sur IDs séquentiels combinée à une absence de rate limiting. Des téraoctets de contenu public extraits archivables avant la fermeture de la plateforme.

Facebook Phone Number Lookup (2019) — IDOR dans une API de recherche d'utilisateur par numéro de téléphone exposant 419 millions d'enregistrements avant correction.

Ces incidents partagent trois signaux communs : IDs numériques séquentiels, absence totale ou partielle de contrôle d'accès au niveau objet, absence de rate limiting qui aurait réduit l'exploitation massive.

Comment tester et détecter

La détection d'IDOR combine tests manuels et outils spécialisés.

Procédure de test manuel en 4 étapes

1. Provisionner deux comptes utilisateurs distincts (A et B) avec des données identifiables.
2. Cartographier tous les endpoints qui manipulent un identifiant côté URL, paramètre, corps JSON ou en-tête. Inclure GET, POST, PATCH, PUT, DELETE.
3. Capturer les requêtes authentifiées du compte A et substituer ses IDs par ceux du compte B tout en conservant sa propre session.
4. Comparer les réponses : HTTP 200 avec données de B = IDOR confirmée, 403/404 = contrôle probablement correct (à vérifier dans les logs serveur).

Outils spécialisés en 2026

Points de test souvent oubliés

• Opérations non-GET (PATCH, PUT, DELETE) : la plupart des test se concentrent sur les GET.
• IDs dans les en-têtes customs (X-Tenant-Id, X-User-Context) et non seulement dans l'URL.
• IDs dans les bodies JSON imbriqués ({ "order": { "id": 123, "userId": 456 } }).
• GraphQL : les IDs passent dans les variables et les queries, tester chaque mutation séparément.
• WebSocket : souvent oublié, messages authentifiés manipulables.
• Query parameters cachés ou découverts via Arjun/Param Miner.

Comment prévenir efficacement

Une défense robuste contre l'IDOR repose sur quatre lignes de défense, à implémenter toutes ensemble.

1. Contrôle d'accès centralisé au niveau objet

Une seule fonction canAccess(user, resource, action) appelée systématiquement avant chaque opération, basée sur la relation de propriété, le rôle et le tenant.

# Pattern de contrôle d'accès centralisé en Python
from functools import wraps
from flask import abort, g, request
 
def authorize(resource_type: str, action: str):
    """Décorateur de contrôle d'accès, appelé sur chaque route sensible."""
    def decorator(func):
        @wraps(func)
        def wrapped(*args, **kwargs):
            resource_id = kwargs.get("resource_id") or request.view_args.get("id")
            resource = load_resource(resource_type, resource_id)
            if not resource:
                abort(404)
            if not can_access(g.current_user, resource, action):
                # Log pour SIEM + retour 404 pour éviter la fuite d'existence
                audit_log("unauthorized_access", g.current_user.id, resource_type, resource_id)
                abort(404)
            return func(*args, **kwargs)
        return wrapped
    return decorator
 
@app.route("/api/orders/<order_id>", methods=["GET"])
@authorize("order", "read")
def get_order(order_id):
    return jsonify(load_resource("order", order_id).to_dict())

2. Identifiants non prédictibles (défense complémentaire)

• Préférer UUID v4 aux IDs séquentiels pour les ressources utilisateur.
• Pour les URLs publiques partageables, utiliser des tokens de ressource chiffrés (JWE) avec durée de vie.
• Les UUID réduisent la surface d'énumération mais ne remplacent pas un contrôle d'autorisation.

3. Références indirectes

Dans les contextes à forte sensibilité, exposer côté client un identifiant de session éphémère (reference_key) mappé côté serveur vers l'objet réel. Pattern documenté dans OWASP ASVS V4.2.

4. Tests automatisés d'autorisation

• Tests d'intégration CI : scénarios explicites avec 2 utilisateurs testant chaque endpoint.
• Tests de régression à chaque modification de route ou de service.
• Pentest manuel annuel complémentaire pour les cas de logique métier.
• Bug bounty en production pour les cas non couverts par tests internes.

Points clés à retenir

• Définition : exposition d'identifiant d'objet + manipulation possible + absence de vérification d'autorisation au niveau objet.
• Classification 2026 : OWASP Top 10 A01:2021 (Broken Access Control) / OWASP API Security Top 10 API1:2023 (BOLA) / CWE-639 / WSTG-ATHZ-04.
• Trois types : IDOR horizontale (même niveau utilisateur), verticale (élévation privilège), référence fichier/ressource.
• Fréquence : première cause de vulnérabilités critiques en API (30-40 % selon Salt Security 2024), 94 % des apps ont au moins un défaut Broken Access Control (OWASP).
• Détection : 2 comptes + Burp Autorize / AuthMatrix + tests sur toutes méthodes HTTP + endpoints API et WebSocket inclus.
• Prévention : contrôle d'accès centralisé canAccess(user, resource, action) + UUID non prédictibles + tests d'intégration CI + bug bounty en production.
• Réponse HTTP : privilégier 404 plutôt que 403 pour éviter la fuite d'existence d'objet.
• Incidents majeurs : First American (885M), T-Mobile (2M), USPS (60M), Facebook Phone Lookup (419M) — tous partagent IDs séquentiels + absence de contrôle objet.

Pour aller plus loin

• Introduction à l'OWASP Top 10 — panorama des 10 risques majeurs dont A01 (famille des IDOR).
• Secure coding : définition, principes et référentiels 2026 — principes de développement défensif qui préviennent les IDOR à la source.
• Roadmap AppSec 2026 — trajectoire d'apprentissage pour un AppSec Engineer confronté quotidiennement aux IDOR.
• Roadmap API Security 2026 — spécialisation spécifique sur BOLA et les défauts API modernes.
• Roadmap secure coding 2026 — parcours structuré pour maîtriser les contre-mesures.