Apprenez ce que signifie l'expression "Insecure Direct Object Reference" (IDOR), comment les attaquants l'exploitent et comment les développeurs peuvent prévenir les vulnérabilités IDOR en utilisant des pratiques de codage sécurisées, des modèles de contrôle d'accès et des plates-formes de test automatisées.

Qu'est-ce que l'IDOR ?

L'IDOR (Insecure Direct Object Reference) est une faille de sécurité dans laquelle une application expose des identifiants d'objets internes - tels que des identifiants d'utilisateurs, des numéros de commande ou des noms de fichiers - sans vérifier si le demandeur est autorisé à accéder à l'objet en question. En changeant un paramètre dans une URL ou un appel API, un attaquant peut voir, modifier ou supprimer des données auxquelles il ne devrait pas avoir accès.

Comprendre l'IDOR : pourquoi cette vulnérabilité est toujours d'actualité

L'IDOR appartient à la vaste catégorie des Contrôle d'accès défaillantque l'OWASP considère depuis des années comme l'un des risques les plus critiques en matière de sécurité sur le web. Le danger de l'IDOR réside dans sa simplicité : l'attaquant n'a pas besoin de techniques d'exploitation avancées, de codage de la charge utile ou d'escalade des privilèges. Un seul paramètre modifié - souvent un simple chiffre - peut exposer des informations privées.

Un modèle vulnérable typique se présente comme suit :

bash

/api/utilisateur/profil?id=1002

Si l'application ne vérifie pas la propriété ou l'autorisation, la modification de l'ID en 1003 peut révéler les données d'un autre utilisateur.

Les applications modernes, en particulier celles qui impliquent des API, des microservices ou des clients mobiles, s'appuient souvent sur l'accès paramétré aux objets. Cette architecture, bien que rapide et flexible, peut facilement introduire l'IDOR lorsque les contrôles d'autorisation sont incohérents ou manquants.

CVE-2025-13526 : Un cas réel d'IDOR dans la nature

L'un des exemples les plus récents et les plus visibles d'exploitation de l'IDOR est le suivant CVE-2025-13526Le logiciel OneClick Chat to Order (versions ≤ 1.0.8), un plugin populaire de WordPress, est affecté par ce problème.

• La vulnérabilité se trouve dans le fichier wa_order_thank_you_override fonction. Le plugin fait confiance à un order_id de la chaîne de requête de l'URL - sans vérifier que la demande émane du propriétaire légitime de la commande.
• Les attaquants (même ceux qui ne sont pas authentifiés) pourraient simplement manipuler le order_id sur l'URL de la page de remerciement (par exemple, en changeant la valeur de l'URL de la page de remerciement). order_id=123456 à order_id=123455) et de récupérer les détails de la commande d'autres clients. Les données exposées sont les suivantes noms, adresses électroniques, numéros de téléphone, adresses de facturation/expédition, articles et prix de la commande, métadonnées relatives au mode de paiement. wiz.io+2Gowri Infosec+2
• Les identifiants de commande étant séquentiels et prévisibles, le dénombrement de masse est devenu trivial, ce qui signifie qu'un pirate ou un script automatisé peut récolter des milliers de commandes en quelques minutes. Moyen+1
• La vulnérabilité a reçu un score de base CVSS v3.1 de 7,5 (élevé), reflétant la facilité d'exploitation (pas d'authentification nécessaire) et la gravité de l'exposition des données.
• Le développeur a corrigé le problème dans la version 1.0.9La mise à jour a été effectuée en mettant en œuvre des contrôles d'autorisation appropriés afin de s'assurer que seuls les propriétaires légitimes (ou les utilisateurs autorisés) peuvent consulter les données relatives aux commandes. Les propriétaires de sites ont été invités à procéder immédiatement à la mise à jour. Gowri Infosec+1

Cette brèche dans le monde réel montre qu'IDOR n'est pas un bogue théorique ou hérité - il est toujours vivant, exploitable et peut avoir de graves conséquences en matière de respect de la vie privée et de conformité.

Scénarios courants dans le monde réel où l'IDOR se produit

L'IDOR peut apparaître dans tout système qui fait référence à des objets internes par le biais d'une entrée contrôlée par l'utilisateur. Vous trouverez ci-dessous des contextes courants :

Type d'application	Exemple d'objet	Pourquoi l'IDOR se produit-il ?
Systèmes de comptes	ID utilisateur	Exposer directement les identifiants des utilisateurs
Applications de commerce électronique	orderId	Validation incorrecte de la propriété
Gestion des fichiers	fileId	Absence de contrôle d'accès aux fichiers
Plateformes de billetterie	ticketId	Les utilisateurs accèdent aux tickets des autres utilisateurs
Applications SaaS multi-locataires	identifiant du locataire	Fuites de données entre locataires

Les attaquants énumèrent souvent des identifiants prévisibles, tentent des identifiants séquentiels ou rejouent des requêtes authentifiées avec des paramètres modifiés.

Comment les attaquants exploitent IDOR (exemples sûrs et contrôlés)

Ci-dessous exemples d'illustrations sûres montrant des modèles vulnérables typiques et leurs équivalents sécurisés. Il ne s'agit pas d'exploits dangereux, mais de modèles d'erreurs courantes pour aider les développeurs à reconnaître les modèles dangereux.

Exemple 1 : IDOR dans Node.js / Express

javascript

// Exemple : confiance dans l'identifiant fourni par l'utilisateur

app.get('/api/user/profile', (req, res) => {

const userId = req.query.id ;

db.users.findById(userId).then(user => {

res.json(user) ;

});

});

// ✅ Exemple de sécurité : appliquer l'autorisation

app.get('/api/user/profile', (req, res) => {

const authenticatedId = req.user.id ;

db.users.findById(authenticatedId).then(user => {

if (!user) return res.status(404).json({ error : "User not found" }) ;

res.json({ id : user.id, email : user.email, role : user.role }) ;

});

});

Exemple 2 : Un modèle courant en Python / Flask

python

#❌ Insécurisé : pas de validation de propriété

@app.get("/invoice")

def get_invoice() :

invoice_id = request.args.get("id")

return get_invoice_by_id(invoice_id)

#✅ Secure : vérification des permissions ajoutée

@app.get("/invoice")

def get_invoice_secure() :

invoice_id = request.args.get("id")

user_id = session["user_id"]

invoice = get_invoice_by_id(invoice_id)

if invoice.owner_id != user_id :

return {"error" : "Unauthorized"}, 403

facture de retour

Exemple 3 : Défense combinée back-end et front-end (Java + React)

Java (Spring Boot)

java

// ❌ Contrôle d'autorisation manquant

@GetMapping("/orders")

public Order getOrder(@RequestParam String orderId) {

return orderRepository.findById(orderId) ;

}

// ✅ Mise en œuvre sécurisée

@GetMapping("/orders")

public ResponseEntity getOrder(

@RequestParam String orderId,

Principal principal) {

Order order = orderRepository.findById(orderId) ;

if (!order.getUser().equals(principal.getName()))) {

return ResponseEntity.status(HttpStatus.FORBIDDEN)

.body(Collections.singletonMap("error", "Access denied")) ;

}

return ResponseEntity.ok(order) ;

}

Demande sécurisée côté React

javascript

async function fetchOrder(orderId) {

const res = await fetch(/orders?orderId=${orderId}, {

headers : { "Authorization" : Bearer ${localStorage.getItem("token")} }

});

if (!res.ok) throw new Error("Unauthorized or not found") ;

return res.json() ;

}

Détection des vulnérabilités IDOR : Approches pratiques des développeurs

Il est souvent plus difficile de trouver l'IDOR que de l'exploiter. Contrairement aux vulnérabilités par injection, l'IDOR ne produit pas toujours des erreurs techniques évidentes - ses symptômes sont logiques et comportementaux.

Les techniques de détection les plus courantes sont les suivantes :

1. Fuzzing différentiel (test de plusieurs identifiants)
2. Test de relecture (capture → modification → relecture)
3. Changement de rôle multi-utilisateurs
4. Énumération des paramètres

Pseudo-code de fuzzing sûr :

python

Exemple simple de fuzzing sécurisé

ids = ["1001", "1002", "1003"]

pour i dans ids :

res = client.get(f"/api/user/profile?id={i}")

print(i, res.status_code, len(res.text))

Prévention de l'IDOR : les meilleures pratiques que les développeurs doivent suivre

La prévention de l'IDOR n'est pas une question d'obscurité, c'est une question de autorisationLes résultats ont été constants au niveau du serveur.

Ne jamais faire confiance aux identifiants d'objets provenant du client

Chaque paramètre est modifiable. Même les identifiants cryptés peuvent être falsifiés.

Renforcer l'autorisation côté serveur pour chaque requête

Utiliser des modèles de contrôle d'accès reconnus :

• RBAC (Contrôle d'accès basé sur les rôles)
• ABAC (Contrôle d'accès basé sur les attributs)
• ACL (Listes de contrôle d'accès)
• La politique en tant que code des systèmes tels que OPA

Ressources de l'autorité :

• OWASP : https://owasp.org

PortSwigger Web Security Academy : https://portswigger.net/web-security/access-control

Préférer les identifiants non dénombrables

Les UUID réduisent, mais n'éliminent pas, le risque d'IDOR.

Valider les limites des locataires dans les environnements multi-locataires

L'IDOR entre locataires est l'une des formes les plus graves et les plus coûteuses.

Utiliser une couche "backend-for-frontend" (BFF)

Un BFF peut centraliser la logique d'autorisation, réduisant ainsi les incohérences entre les clients.

Autres exemples avancés

Exemple 4 : API Go avec autorisation manquante

aller

// ❌ Vulnerable handler

func GetDocument(w http.ResponseWriter, r *http.Request) {

id := r.URL.Query().Get("id")

doc := db.FindDocument(id)

json.NewEncoder(w).Encode(doc)

}

// ✅ Avec validation de la propriété

func GetDocumentSecure(w http.ResponseWriter, r *http.Request) {

id := r.URL.Query().Get("id")

user := r.Context().Value("user").(string)

doc := db.FindDocument(id)

if doc.Owner != user {

http.Error(w, "Unauthorized", http.StatusForbidden)

retour

}

json.NewEncoder(w).Encode(doc)

}

Exemple 5 : Points d'extrémité GraphQL et autorisation des objets

javascript

// ❌ Résolveur vulnérable

const resolvers = {

Demande de renseignements : {

order : (_, { id }) => db.getOrder(id),

}

};

// ✅ Résolveur sécurisé avec vérification de la propriété

const resolversSecure = {

Demande de renseignements : {

order : (_, { id }, context) => {

const order = db.getOrder(id) ;

if (order.owner !== context.user.id) {

lancer une nouvelle erreur ("Accès refusé") ;

}

ordre de retour ;

}

}

};

Exemple 6 : Accès sécurisé en rouille (Actix Web)

rouille

// Vulnérable

async fn get_ticket(path : web::Path) -> impl Responder {

let id = path.into_inner() ;

let ticket = db::find_ticket(&id) ;

web::Json(ticket)

}

// ✅ Version sécurisée

async fn get_ticket_secure(

path : web::Path,

utilisateur : LoggedInUser

) -> impl Responder {

let id = path.into_inner() ;

let ticket = db::find_ticket(&id) ;

if ticket.owner != user.id {

return HttpResponse::Forbidden().json("Accès refusé") ;

}

HttpResponse::Ok().json(ticket)

}

Automatisation de la détection d'IDOR : Pourquoi les outils traditionnels se heurtent à des difficultés

La plupart des scanners de vulnérabilités traditionnels ne peuvent pas détecter l'IDOR de manière fiable parce que l'IDOR exige deux choses que les scanners ne font traditionnellement pas :

1. Sensibilisation à la logique d'entreprise
2. Tests contextuels multi-utilisateurs

Les outils d'analyse qui s'appuient uniquement sur la détection basée sur les signatures ou sur les requêtes d'un seul utilisateur passent généralement complètement à côté de l'IDOR, en particulier dans les API.

Comment Penligent aide à identifier automatiquement l'IDOR

C'est ici que PenligentPenligent, une plateforme de test de pénétration pilotée par l'IA, offre un avantage unique. Contrairement aux scanners conventionnels, Penligent effectue :

• Simulation automatique multi-utilisateurs
• Inférence de paramètres entre objets
• Reconnaissance intelligente des modèles d'identification
• Analyse différentielle du comportement
• L'intelligence artificielle qui s'adapte en fonction des réponses observées

Un échantillon du résultat de la détection sécurisée et anonyme de Penligent :

vbnet

`Potentiel IDOR détecté:Endpoint : /orders?id=1002Comportement observé :

• L'utilisateur A a reçu la commande #1003 (appartenant à l'utilisateur B). Risque : Accès non autorisé aux données d'un autre utilisateur.

Il est difficile d'obtenir ce type d'informations à l'aide d'outils statiques ou d'un examen manuel.

Réduire les risques d'IDOR à travers CI/CD avec Penligent

Penligent s'intègre naturellement dans les pipelines CI/CD et fournit une couverture continue :

• Découverte automatique de l'API et des itinéraires
• Inférence de la matrice de permission en temps réel
• Analyse des environnements d'essai et de production
• Génération automatique de séquences de PoC sûres et reproductibles

Cela réduit :

• Taches aveugles de la logique d'entreprise
• Exposition à des locataires multiples
• Risques réglementaires (GDPR, HIPAA, SOC2)

Conclusion : L'IDOR est simple mais dévastateur - et évitable

L'IDOR reste l'une des formes les plus courantes et les plus préjudiciables de vulnérabilité en matière de contrôle d'accès. Parce qu'il se cache dans la logique de l'entreprise, il échappe souvent aux outils traditionnels. En appliquant des contrôles d'autorisation cohérents, en utilisant des identifiants non prévisibles, en validant les limites des locataires et en adoptant des plateformes de test automatisées comme Penligent, les organisations peuvent réduire considérablement le risque d'exposition des données à grande échelle.

L'IDOR ne peut pas être totalement éliminé par hasard ou par de bonnes intentions - il nécessite un contrôle d'accès structuré, des principes d'ingénierie cohérents et des tests continus.