Comment j'ai trouvé une IDOR critique en bug bounty avec mon propre outil
Récit d'une IDOR critique trouvée sur un programme bug bounty via une mutation GraphQL non protégée détectée par Sentinelle en quelques minutes.
J’ai trouvé une IDOR critique sur un programme bug bounty avec mon propre outil Sentinelle
Voici exactement comment, étape par étape.
C’est le genre de vulnérabilité qui se cache dans les mutations GraphQL que presque personne ne regarde vraiment.
L’attaque en une phrase
Une mutation GraphQL acceptait un userId directement dans le corps de la requête, sans vérifier que l’utilisateur authentifié avait réellement le droit de modifier ce profil.
Résultat : n’importe quel utilisateur connecté pouvait changer l’email d’un autre compte puis prendre le contrôle total via reset de mot de passe.
Étape 1 Sentinelle détecte l’API GraphQL
Je lance Sentinelle sur le scope autorisé.
Quelques secondes plus tard, l’agent identifie un endpoint /graphql et tente automatiquement une introspection la méthode standard permettant de récupérer le schéma complet d’une API GraphQL.
Résultat :
schéma exposé en production
types accessibles
queries visibles
mutations entièrement listées
Première red flag : laisser l’introspection activée en production est presque toujours une mauvaise idée.
Étape 2 Une mutation anormale
Sentinelle mappe automatiquement toutes les mutations et leurs arguments.
Une attire immédiatement l’attention :
mutation updateUserProfile(userId: ID!, email: String, ...)Le problème saute aux yeux :
le userId est fourni directement côté client.
C’est un pattern classique d’IDOR.
Si le backend ne revalide pas que l’utilisateur authentifié possède les droits sur l’objet ciblé, n’importe quel compte peut potentiellement modifier celui d’un autre utilisateur.
Étape 3 La validation du bug
Je me connecte avec un compte de test.
Je récupère ensuite l’ID d’un autre utilisateur trivialement accessible via une query publique puis j’exécute la mutation suivante :
mutation {
updateUserProfile(
userId: "VICTIM_ID",
email: "attacker@evil.com"
)
}Réponse :
200 OKLe profil de la victime est modifié.
Aucune vérification d’autorisation.
Aucune restriction côté serveur.
Étape 4 L’impact réel
À partir de là, n’importe quel utilisateur authentifié peut :
modifier l’email d’un autre compte
déclencher un reset de mot de passe
recevoir le lien de réinitialisation
prendre le contrôle complet du compte
accéder aux données privées de la victime
Sur une plateforme avec une base utilisateurs importante, c’est un scénario de takeover massif.
CVSS estimé : supérieur à 9.
Ce que Sentinelle a fait automatiquement
Pendant que je validais le comportement métier, l’agent avait déjà :
détecté GraphQL automatiquement
confirmé que l’introspection était activée
cartographié toutes les mutations
identifié les arguments sensibles (
*Id)généré des payloads de test exploitables immédiatement
préparé les requêtes de validation
Ce qui m’aurait pris plusieurs heures de recon manuelle et de revue de schéma a été réduit à quelques minutes.
Mon rôle s’est résumé à :
valider l’impact
relire le rapport
soumettre le bug
Le vrai problème avec GraphQL
Les mutations GraphQL sont probablement l’un des angles morts les plus fréquents en bug bounty aujourd’hui.
Le pattern revient constamment :
le front-end envoie librement des IDs
le backend suppose que l’authentification suffit
personne ne vérifie réellement l’autorisation au niveau de l’objet ciblé
Et c’est exactement là que les IDOR apparaissent.
La règle à retenir
Chaque mutation qui accepte un identifiant d’objet (userId, accountId, projectId, etc.) doit revalider les autorisations côté serveur.
Pas seulement vérifier la session.
Vérifier explicitement que l’utilisateur a le droit d’agir sur cet objet précis.
C’est cette différence qui sépare une API sécurisée d’une prise de contrôle de compte.
Takeaway
Les agents offensifs changent complètement la vitesse à laquelle ce type de vulnérabilité peut être découvert.
La détection ne repose plus uniquement sur de longues heures de recon manuelle ou sur l’intuition d’un pentester.
Le raisonnement devient automatisable.
Et les workflows GraphQL mal sécurisés deviennent des cibles extrêmement faciles à explorer à grande échelle.
Si tu fais du bug bounty, les mutations GraphQL sont probablement un meilleur terrain de chasse aujourd’hui que beaucoup de surfaces “classiques”.
Cet article vous a plu ?
Écrit par
Chris
Constructeur de solutions tech · IA agentique & sécurité offensive
Passionné de tech et constructeur de produits, je bâtis Sentinelle — un agent IA autonome de sécurité offensive. J'écris ici sur l'IA agentique, le pentest assisté par IA et ce que j'apprends en construisant des outils offensifs.
