Test IDOR pour les vulnérabilités de visualisation par lien copié dans votre application

À quoi ressemble la « visualisation par lien copié » dans les applis réelles

« Copy-link viewing » se produit lorsqu'on peut ouvrir une page dans votre application simplement en collant un lien, alors qu'on n'est pas censé voir cet enregistrement. On le rencontre souvent sur les factures, projets, tickets de support, documents partagés, et parfois sur des écrans d'administration qui incluent un bouton « Copy link ».

Le risque ne vient pas de la fonctionnalité de partage. Le risque, c'est que l'application charge des données uniquement en fonction de ce qui est dans l'URL (par exemple un ID) sans vérifier si l'utilisateur courant est autorisé à les voir.

Un exemple courant : un client copie un lien vers sa facture et l'envoie à son comptable. Le comptable clique dessus en étant connecté sur son propre compte (ou pas du tout connecté) et voit quand même la facture. Pire encore, si l'URL ressemble à /invoice/1042, la remplacer par /invoice/1043 peut afficher la facture d'un autre client.

Beaucoup d'équipes pensent être protégées parce que le lien « a l'air aléatoire » (une longue chaîne). Mais l'aléa n'est pas une permission. Si le serveur ne vérifie pas l'accès à chaque fois, un lien à l'apparence aléatoire peut tout de même fuiter des données via le partage, le transfert, l'historique du navigateur, des captures d'écran ou la simple réutilisation d'un ancien message.

Les gens signalent généralement ce comportement comme « étrange », par exemple :

• « J'ai cliqué sur un lien et j'ai vu le nom ou l'email de quelqu'un d'autre. »
• « Je peux ouvrir un ancien lien dans une fenêtre privée et il fonctionne encore. »
• « Mon collègue peut voir mon enregistrement sans y être ajouté. »
• « Le support a demandé un lien, et maintenant toute personne qui l'a peut voir le ticket. »

Ce guide vous conduit pas à pas pour réaliser un simple test IDOR à deux comptes afin de détecter un accès direct non sécurisé sans lire le code. Vous apprendrez quoi essayer, ce qui compte comme une fuite, et comment capturer des preuves exploitables par un développeur.

IDOR expliqué sans jargon sécurité

IDOR signifie insecure direct object access. En termes simples, cela veut dire que vous pouvez changer un ID dans un lien (ou une requête) et voir les données d'une autre personne. L'application renvoie un objet réel (un projet, une facture, un message ou un fichier) principalement en fonction d'un identifiant, sans vérifier correctement si vous êtes autorisé à le voir.

Un schéma typique : vous ouvrez une page et l'URL inclut l'ID d'un élément. Si vous remplacez cet ID par un autre et que l'app affiche l'élément d'une autre personne, c'est un bug d'autorisation.

La distinction clé est simple :

• L'authentification répond : « Êtes‑vous connecté ? »
• L'autorisation répond : « Êtes‑vous autorisé à accéder à cet élément précis ? »

Beaucoup d'apps gèrent correctement la première question et échouent sur la seconde. Être connecté prouve seulement que vous êtes un utilisateur. Cela ne prouve pas que vous devriez voir tous les enregistrements.

Un modèle mental utile :

• Objet : la chose que vous essayez d'accéder (document, commande, ticket)
• Propriétaire : l'utilisateur ou l'équipe à qui l'objet appartient
• Vérification de permission : l'app doit confirmer, à chaque fois, que l'utilisateur courant a accès à cet objet

Si cette vérification manque ou est trop laxiste, le comportement « copy link » peut devenir une exposition accidentelle de données.

Où les bugs IDOR se cachent le plus souvent

Les problèmes IDOR n'apparaissent pas sur les pages marketing. Ils apparaissent dans les parties « travail réel » de l'app, où des enregistrements sont chargés par ID et où existent des actions comme le téléchargement ou l'export.

Pages qui chargent un seul enregistrement par ID

Celles-ci sont courantes car l'URL correspond souvent à un seul enregistrement :

• Factures, reçus, propositions, rapports, PDFs signés
• Projets, tâches, tickets, notes, commentaires
• Profils, pages de facturation, paramètres, écrans admin d'équipe ou workspace
• Pièces jointes, exports, téléchargements d'images/fichiers
• Pages de « partage » qui semblent publiques mais sont censées être privées

Un contrôle rapide : si la page change complètement lorsque vous ne modifiez qu'un seul numéro ou un seul token dans l'adresse, il se peut qu'elle fasse trop confiance à l'ID.

APIs en arrière-plan qui fuient encore

Beaucoup d'apps chargent des données depuis une API en arrière-plan. Parfois l'écran est protégé, mais le endpoint API ne l'est pas.

Exemple : la page du ticket est bloquée, mais un endpoint comme getTicket?id=123 renvoie quand même les détails du ticket à n'importe quel utilisateur connecté.

Si vous avez hérité d'une app générée par l'IA (Lovable, Bolt, v0, Cursor, Replit), soyez particulièrement prudent. Le contrôle d'accès est souvent incohérent entre les routes, surtout pour les téléchargements, les exports et les endpoints « secondaires ».

Préparez le test à deux comptes en toute sécurité

Vous imitez ce qu'un utilisateur réel pourrait faire avec un lien partagé. Faites‑le en toute sécurité : comptes utilisateurs normaux, données de test, sessions séparées.

1. Créez deux utilisateurs réguliers : Compte A et Compte B. Ne donnez aucun des deux de droits admin ou de rôle « voir tout ».
2. Si votre app a des workspaces, organisations ou équipes, placez A et B dans des structures différentes.
3. Avec le Compte A, créez 1–2 éléments de test évidents que vous reconnaîtrez ensuite (par exemple un doc intitulé « IDOR Test - A » ou une fausse facture à 1$). Utilisez des données factices.
4. Notez ce qui devrait se passer. Par exemple : « Seul le propriétaire peut voir » vs « Toute personne avec le lien peut voir, mais pas éditer. »
5. Séparez les sessions pour que les connexions ne se mélangent pas :

• Compte A dans une fenêtre de navigateur normale
• Compte B dans une fenêtre incognito/privée (ou un profil navigateur différent)

Étape par étape : le test de visualisation par lien copié

Le test est simple : Compte A peut voir un élément, puis Compte B essaie d'ouvrir exactement le lien copié.

1. Connectez‑vous en tant que Compte A et ouvrez l'élément cible (facture, projet, ticket, document, fil de messages).
2. Copiez l'URL complète depuis la barre d'adresse. Remarquez tout ce qui ressemble à un identifiant (numéro, chaîne de type UUID, slug lisible).
3. Dans la session séparée, connectez‑vous en tant que Compte B.
4. Collez le lien exact et chargez‑le.
5. Si quelque chose se charge, essayez une petite variation en ne changeant que l'identifiant et en rechargeant.

Après la page de visualisation, répétez le même schéma sur les « portes secondaires » qui fuient souvent plus que l'écran principal. Ne faites rien de destructif.

• S'il existe une route d'édition, voyez si le Compte B peut charger le formulaire d'édition.
• S'il existe une action de téléchargement/export (PDF, CSV, pièce jointe), voyez si elle renvoie un fichier.
• Si la page se charge, notez quelles données supplémentaires apparaissent (noms, emails, montants, notes internes).

Si le Compte B peut voir quoi que ce soit de réel, même un aperçu ou des métadonnées, considérez cela comme un bug d'autorisation.

Comment interpréter les résultats (et ce qui compte comme fuite)

Ne cherchez pas seulement un spectaculaire « je vois tout ». De nombreux problèmes réels fuient juste assez d'informations pour causer des dégâts.

Quels résultats signifient quoi

Comparez ce que le Compte B peut faire avec le lien du Compte A :

• Accès complet : B voit le même contenu que A. Fuite claire.
• Données partielles : B ne peut pas utiliser la page normalement, mais voit tout de même des noms, montants, messages, pièces jointes. Toujours une fuite.
• Métadonnées uniquement : B apprend que l'enregistrement existe (titre, propriétaire, horodatages). Toujours une fuite.
• Refus correct : B est bloqué de façon cohérente et aucune donnée privée n'apparaît.

Un « 404 Not Found » n'est pas toujours sûr. Si certains IDs renvoient 404 tandis que d'autres renvoient une erreur différente, une page différente ou ont un temps de réponse visiblement différent, vous pouvez en fait divulguer l'existence de certains enregistrements.

Surveillez les fuites silencieuses

Certaines apps cachent l'interface mais chargent quand même les données. La page peut sembler vide, mais la réponse (ou un fichier téléchargé) contient des informations privées.

Faites aussi attention aux confusions de permissions : la visualisation est bloquée, mais le Compte B peut encore éditer, supprimer, télécharger ou exporter.

Testez sur desktop et mobile. Les vues mobiles frappent parfois des endpoints différents.

Capturer des preuves exploitables par un développeur

Un bon rapport évite des heures de recherche.

Collectez :

• L'URL exacte utilisée (chemin complet et tout ID visible)
• Date/heure, environnement (production vs staging) et navigateur/appareil
• Preuves depuis les deux comptes (captures d'écran ou courte vidéo)

Quand vous capturez des écrans, incluez un élément qui prouve quel compte est connecté (icône de profil, email, nom de compte). Sinon la reproduction échouera.

Écrivez la règle qui aurait dû être appliquée, en langage clair :

• « Le Compte B ne doit voir que ses propres factures. »
• « Seuls les membres invités du projet peuvent voir ce document. »
• « Seul l'expéditeur et le destinataire peuvent lire ce fil. »

Puis listez exactement ce qui a été exposé (noms, emails, adresses, montants, notes, pièces jointes). Gardez les données de test factices et inoffensives.

Checklist rapide : scan IDOR en 5 minutes

Utilisez deux comptes réguliers (pas d'admin). Choisissez quelques types d'éléments qui devraient être privés entre utilisateurs.

• Confirmez que les deux comptes ont le même rôle et permissions.
• Testez au moins trois types d'éléments (par exemple : un document, un fichier uploadé, et une page de facturation).
• Pour chaque type, testez plus que la vue (« edit/load form, download/export »).
• Faites une modification « devinable » (par exemple /items/104 → /items/105, ou échangez un slug lisible).
• Vérifiez le comportement en cas de refus : les accès non autorisés et les IDs invalides doivent échouer de manière sûre et cohérente.

Essayez aussi en étant déconnecté dans une fenêtre privée. Les pages privées ne doivent pas afficher de contenu rien qu'avec une URL.

Erreurs de test courantes qui font rater le bug

Les équipes exécutent souvent ce test une fois, ne voient rien d'évident et s'arrêtent. Quelques motifs masquent régulièrement le problème.

• Tester deux comptes dans le même workspace ou org (les bugs apparaissent souvent entre orgs).
• Confondre les « share links » intentionnels avec des liens privés (ces derniers doivent toujours vérifier l'identité).
• Penser qu'un long ID protège. Si le serveur ne vérifie pas la permission, tout ID valide suffit.
• Ne regarder que l'UI et pas les téléchargements/exports ou les données en arrière-plan.
• S'arrêter après une seule page. Des écrans similaires sont souvent implémentés avec des règles différentes.

Approche pratique : testez la page de détail, le endpoint de téléchargement/export, et toute vue « activité/commentaires » liée au même objet.

Un exemple simple à comparer avec votre app

Imaginez un portail client où chaque client peut consulter ses factures. Avec le Compte A, ouvrez une facture et cliquez « Copy link ».

Passez au Compte B (un client différent) et collez la même URL de facture.

Si le Compte B peut voir les totaux, les lignes, le nom du client ou télécharger le PDF, c'est une vulnérabilité de visualisation par lien copié. L'app fait plus confiance au lien (ou à l'ID qu'il contient) qu'aux permissions de l'utilisateur connecté.

Ce qui devrait se passer : l'app bloque l'accès sauf si le Compte B est autorisé à voir cette facture. Cela peut être un écran d'accès refusé, une redirection ou une invite de connexion. Si votre produit supporte le partage, le lien ne doit fonctionner que s'il a été explicitement partagé et le partage doit pouvoir être révoqué.

Quand vous le signalez en interne, restez précis :

• Impact : « Tout utilisateur connecté peut voir les factures d'autres clients en collant un lien copié. »
• Zones affectées : « Page de détail facture et téléchargement PDF. »
• Repro : « Se connecter en A, copier le lien, se connecter en B, coller le lien, constater que les données/PDF se chargent. »
• Exemple de données vues : « Total facture $X, nom de facturation, contenu du PDF. »

Comment corriger et quoi faire ensuite

La correction qui fonctionne vraiment

Si votre test à deux comptes montre une visualisation par lien copié, la correction se trouve rarement dans l'UI. Elle se situe côté serveur : à chaque fois que l'app lit ou modifie un enregistrement, elle doit confirmer que l'utilisateur connecté est autorisé à accéder à cet enregistrement précis.

Ne comptez pas sur des boutons cachés, des vérifications côté client ou des IDs « non devinables ». Si un utilisateur peut coller un lien, changer un ID et voir les données d'un autre, la vérification de permission manque ou est incomplète.

Ce qu'il faut appliquer sur chaque endpoint vulnérable :

• Exiger l'authentification quand la page n'est pas publique
• Vérifier l'autorisation pour cet objet précis (propriétaire, membre du workspace, rôle)
• Refuser par défaut
• Appliquer la même règle aux lectures, écritures, exports et téléchargements
• Logger les tentatives refusées pour repérer les abus

Étapes suivantes

Après le déploiement des corrections, relancez le même test à deux comptes sur les mêmes pages et téléchargements que vous aviez utilisés. Corriger une route laisse souvent une « porte secondaire » ouverte.

Si l'app a été générée rapidement avec des outils comme Lovable, Bolt, v0, Cursor ou Replit, prévoyez du temps supplémentaire. Ces projets ont fréquemment plusieurs routes touchant les mêmes données.

Si vous souhaitez de l'aide pour confirmer l'étendue et patcher proprement le contrôle d'accès, FixMyMess (fixmymess.ai) se spécialise dans le diagnostic et la réparation des bases de code générées par IA, y compris les bugs d'autorisation, le renforcement de la sécurité et la préparation au déploiement.