Un IDOR qui exposait
toute la base clients d'un assureur.

Le contexte

Une compagnie d'assurance française de taille intermédiaire, sans révéler la taille exacte qui permettrait de l'identifier. Plusieurs dizaines de milliers de clients particuliers, une équipe IT interne d'une vingtaine de personnes, une infrastructure majoritairement gérée en interne. Le pentest applicatif est annuel, demandé par le RSSI dans une démarche d'amélioration continue, mais aussi avec un objectif de conformité face à l'ACPR et aux exigences RGPD du secteur.

Périmètre cadré au démarrage : le portail client (parcours souscription, gestion de contrats, déclaration de sinistre, paiement de primes), l'API back-end qui le dessert, et la zone d'administration interne accessible aux téléconseillers. Pas de Red Team, pas d'attaque sur l'infrastructure réseau interne, pas de phishing : du pentest applicatif pur, en boîte grise (comptes de test fournis).

Jour 1 : reconnaissance et cartographie

Le premier jour de mission est rarement spectaculaire. On cartographie la surface d'attaque : tous les endpoints accessibles, toutes les fonctionnalités du portail, toutes les requêtes API qui passent en background. On commence à mapper les rôles utilisateurs, les permissions par fonction, les flux de données.

Sur ce portail, deux types de comptes de test fournis : un compte client standard (un dossier à son nom, des contrats actifs, l'historique normal), et un compte interne avec des droits administratifs. On commence par le compte standard et on observe la navigation. Tout semble propre en apparence : authentification correcte, redirection HTTPS, session bien gérée.

Jour 2 : la découverte (par hasard, comme souvent)

Le pattern qui pose problème apparaît en milieu de matinée. En naviguant dans l'espace client, on tombe sur l'URL d'affichage du dossier :

https://espace-client.assureur.fr/dossier/784521

Un identifiant numérique séquentiel. Premier réflexe de pentester : incrémenter et observer.

https://espace-client.assureur.fr/dossier/784522

La page se charge. Sans erreur. Sans message « accès refusé ». Sans redirection vers la page de login. Et à l'écran s'affiche le dossier complet d'un autre client. Nom, adresse, date de naissance, numéro de contrat, IBAN, primes en cours, sinistres déclarés. Pas une vue partielle, pas une page tronquée : le dossier complet, comme si on était le propriétaire.

On vérifie qu'on n'a pas mal lu. On essaie 784523, puis 784520, puis 100000, puis 999999. Tous accessibles. Le serveur ne vérifie pas si l'identifiant demandé appartient à l'utilisateur connecté. C'est l'archétype de l'IDOR (Insecure Direct Object Reference), faille n°1 du Top 10 OWASP API depuis 2019.

Jour 2 (suite) : démonstration d'impact

Une faille reste théorique tant qu'on n'a pas démontré qu'elle est exploitable à l'échelle. On écrit un script Python d'une trentaine de lignes (boucle, requête, sauvegarde) qui parcourt les identifiants. Pour rester respectueux des règles d'engagement, on extrait un échantillon limité (1 247 dossiers, suffisant pour démontrer la criticité, négligeable par rapport au total) et on s'arrête.

Temps écoulé : 27 minutes. Données extraites : noms complets, adresses postales, dates de naissance, numéros de Sécurité sociale partiels (présents sur certains dossiers), IBAN, contrats, montants des primes, historiques de sinistres.

L'extrapolation à l'ensemble de la base : sous 4 heures, l'intégralité des dossiers clients aurait pu être exfiltrée par un attaquant disposant d'un simple compte client. Et créer un compte client sur ce portail demandait juste un email valide et un numéro de contrat — trivial à fabriquer pour quelqu'un qui aurait déjà eu un seul vrai client comme entrée.

Le rapport et la restitution

Fin de mission au jour 5 (incluant cartographie complète, deux autres findings notables non détaillés ici, rédaction du rapport et restitution orale). Le rapport identifie l'IDOR comme finding critique, score CVSS 9.1 (impact massif sur la confidentialité, exploitation triviale, périmètre élargi : toutes les routes du même pattern probablement vulnérables).

La restitution orale dure 1h30 avec le RSSI, le DSI, le responsable développement applicatif et un délégué à la protection des données. On démontre la faille en direct sur leur environnement (en mode lecture seule, sans extraction), on présente le périmètre potentiel d'autres routes touchées, et on cadre la remédiation par paliers de priorité.

La remédiation (en 48 heures)

Le correctif technique est simple — c'est ce qui rend la faille si frustrante. Côté code, il a suffi d'ajouter une vérification d'autorisation dans le contrôleur qui sert le dossier client. En pseudo-code :

// AVANT (vulnérable)
function get_dossier(id) {
  return db.fetch(id);
}

// APRÈS (corrigé)
function get_dossier(id, user) {
  let dossier = db.fetch(id);
  if (dossier.owner_id !== user.id) {
    throw new ForbiddenException();
  }
  return dossier;
}

Quatre lignes à ajouter. Mais comme le pattern était utilisé sur plus de 240 routes du portail (chaque type de ressource — dossier, contrat, document, attestation, simulation, etc. — exposé via le même mécanisme d'identifiant séquentiel), il a fallu un audit méthodique pour identifier toutes les routes concernées, modifier le code de chacune, et déployer.

Équipe interne mobilisée : 2 développeurs et 1 lead pendant 2 jours, plus tests de non-régression. Hot-fix déployé en production 48h après la restitution. Audit complémentaire 2 semaines après pour vérifier qu'aucune route n'a été oubliée. Aucune autre faille du même type identifiée.

L'impact évité, chiffré

Difficile de chiffrer précisément ce qui n'est pas arrivé, mais ordre de grandeur honnête en cas d'exploitation réelle :

• Notification CNIL sous 72h obligatoire en cas de fuite de données personnelles, avec publication dans le rapport annuel CNIL. Effet réputationnel important pour un assureur.
• Sanction CNIL potentielle jusqu'à 4 % du chiffre d'affaires annuel mondial (en pratique pour ce type de fuite massive sans correction préalable, des amendes de plusieurs millions d'euros ont déjà été prononcées en France).
• Notification individuelle des dizaines de milliers de clients impactés (coût opérationnel direct estimé 5 à 15 € par client : courrier, plateforme de support, prise en charge fraude bancaire).
• Action collective civile possible des clients (procédures judiciaires longues et coûteuses, indemnisations).
• Perte de chiffre d'affaires : taux de churn généralement observé après ce type d'incident chez un assureur : 8 à 15 % sur les 12 mois suivants.
• Coût direct du pentest qui a permis l'éviter : moins de 1 % du coût estimé d'une exploitation réelle.

Ce que cette mission illustre

Trois choses, à mon sens, méritent d'être notées au-delà du cas lui-même :

1. L'IDOR n'est pas une faille « débutante ». Cette compagnie d'assurance n'est pas une startup qui code à la va-vite. C'est une organisation avec des processus qualité, des revues de code, des outils d'analyse statique, et un cycle de release encadré. Et pourtant la faille était là depuis des années. L'IDOR n'apparaît jamais dans les analyseurs statiques parce que c'est une faille logique métier (l'accès est techniquement valide, c'est juste l'autorisation qui est défaillante), invisible à l'œil non averti.

2. Un pentest annuel n'est pas un luxe. Le précédent pentest de cette structure datait de 18 mois. Entre les deux, plusieurs releases applicatives importantes étaient passées. L'IDOR existait probablement dès le départ, ou avait été introduit lors d'une de ces évolutions. Sans le pentest annuel, elle aurait pu rester en place encore des années.

3. Le rapport actionnable change tout. Trouver la faille, c'est 30 % du boulot. Documenter précisément, donner un correctif de référence, accompagner le déploiement, vérifier en post-déploiement, c'est l'autre 70 %. Une faille critique trouvée mais mal documentée ne sera pas corrigée. C'est ce qui fait la différence entre un pentest mené par un consultant qui a fait l'attaque et un PowerPoint produit par un commercial.