Le 2 septembre 2026, plusieurs sites rattachés au ministère de la Transition écologique sont devenus inaccessibles, remplacés par un message de maintenance. Deux jours plus tard, LeMagIT publiait son Cyberhebdo du 4 septembre 2026 : cyberattaque contre le Ministère de la Transition écologique. Ce qui rend cet incident intéressant pour une PME n’est pas sa taille — 22 800 utilisateurs, c’est peu en 2026 — mais son vecteur : il n’y avait rien à patcher.
Ce que l’on sait de l’incident
L’attaque a visé les outils de messagerie et les sites du ministère en exploitant une mauvaise configuration d’API et des failles de type IDOR, pour Insecure Direct Object Reference. Deux fichiers ont été exfiltrés : controleurs.csv, qui contient 14 656 enregistrements relatifs à des contrôleurs, et all_users.json, qui en contient 8 166. Le total avoisine 22 800 utilisateurs.
L’ANSSI a été mobilisée pour conduire les investigations et le ministère a signalé les faits au procureur de la République. Le site de consultation publique environnementale figure parmi les services paralysés.
Retenez la mécanique, parce que c’est elle qui se transpose chez vous. Une faille IDOR, c’est un identifiant exposé — un numéro de dossier, un identifiant d’utilisateur dans une URL ou dans une réponse d’API — que le serveur renvoie sans vérifier que le demandeur a le droit de le consulter. Vous passez de /api/agents/1042 à /api/agents/1043 et vous obtenez la fiche suivante. Répété dans une boucle, ce geste vide une base.
Notre avis d’expert — votre scanner était vert, et il avait raison
C’est le point que je répète le plus souvent en restitution, et celui qui surprend le plus les directions : un tableau de bord entièrement vert n’est pas une preuve d’absence de risque, c’est une preuve d’absence de risque connu.
Un scanner compare ce qu’il trouve à une base de signatures et de versions. Il sait vous dire qu’une bibliothèque est obsolète, qu’un en-tête manque, qu’un port ne devrait pas être ouvert. Il ne sait pas dire que l’utilisateur 1042 ne devrait pas pouvoir lire la fiche 1043, parce que cette règle n’est écrite nulle part ailleurs que dans votre métier. Aucune base de vulnérabilités au monde ne contient vos règles d’habilitation.
C’est la raison pour laquelle les défauts d’autorisation occupent depuis des années le sommet du classement OWASP sous l’intitulé Broken Access Control, tout en restant presque invisibles dans les outils automatiques. Ils ne se détectent pas, ils se testent.
Retour de terrain
Le schéma que nous rencontrons le plus souvent en PME n’est pas l’absence de contrôle d’accès, c’est un contrôle d’accès écrit dans l’interface plutôt que sur le serveur. Le bouton « voir la fiche » n’apparaît pas pour les profils non autorisés, donc l’équipe considère le sujet traité. Mais l’API, elle, répond à qui l’interroge, et il suffit d’ouvrir les outils de développement du navigateur pour l’interroger directement. Masquer un bouton n’est pas un contrôle de sécurité : c’est un choix d’ergonomie. La question à poser à votre prestataire tient en une phrase — « où, dans le code serveur, est écrite la vérification que ce compte a le droit de lire cet objet ? »
Notre avis d’expert — le même jour, l’AMF, à l’autre bout du spectre
Le 4 septembre 2026, une fuite visant l’Association des maires de France et des présidents d’intercommunalité était revendiquée sur un forum cybercriminel. L’auteur, sous le pseudonyme « Alduin », affirme avoir exploité une injection SQL de type UNION pour accéder à la base et en extraire environ 114 000 entrées — étant entendu qu’une entrée n’équivaut pas à une personne distincte.
Les données décrites comprennent noms et prénoms, adresses électroniques, commune ou intercommunalité, fonction et type d’abonnement. Un détail mérite d’être relevé sans détour : selon les éléments publiés, l’une des tables contient des identifiants associés à des mots de passe enregistrés en clair. Maires, élus, directeurs généraux des services, agents RH et juristes figurent dans le jeu de données.
Deux incidents, deux vecteurs opposés — l’un moderne et silencieux, l’autre vieux de vingt-cinq ans — et une seule leçon commune. Dans les deux cas, il ne manquait pas un correctif : il manquait quelqu’un pour tester l’application autrement qu’en cliquant dessus comme un utilisateur normal. C’est aussi ce qui rend ces jeux de données dangereux dans la durée : une identité professionnelle vérifiée, avec fonction et collectivité, alimente un hameçonnage ciblé bien plus crédible qu’une simple liste d’adresses.
Votre espace client répond-il à qui l’interroge ?
Nous testons vos API avec deux comptes de niveaux différents et vous remettons la liste exacte des objets accessibles hors périmètre, avec les requêtes qui le prouvent.
Discutons-en — test d’autorisation d’APINotre avis d’expert — pourquoi une PME est plus exposée qu’un ministère
L’intuition courante veut qu’une administration soit une cible et qu’une PME de trente personnes n’intéresse personne. Sur ce vecteur précis, c’est l’inverse qu’il faut retenir : une faille d’autorisation n’exige ni exploit acheté, ni outillage rare. Un navigateur et un peu de patience suffisent. Le coût d’entrée étant nul, le nombre d’acteurs capables de la trouver est immense, et le ciblage devient largement opportuniste.
Or presque toutes les PME que nous accompagnons exposent une API sans l’avoir formulé ainsi : un espace client, un portail partenaire, une application mobile, une intégration avec un logiciel de facturation ou un CRM. Ces développements ont un profil commun — livrés vite, souvent par un prestataire qui n’est plus là, et jamais testés avec deux comptes distincts. Sur nos 31 clients sous supervision, 19 sont dans ce cas.
Les 3 contrôles lancés le soir même
1. L’énumération d’identifiants. On prend un objet qui appartient légitimement au compte de test — une commande, un dossier, une facture — et on modifie son identifiant dans l’appel d’API. Le serveur doit répondre 403 ou 404. S’il répond 200 avec le contenu du voisin, vous avez exactement la faille du ministère. Ce test prend dix minutes et nous l’avons trouvé positif sur 4 des 19 périmètres examinés.
2. L’élévation horizontale et verticale. On rejoue les appels réservés à un profil administrateur en présentant le jeton d’un compte client standard. Beaucoup d’applications vérifient le rôle au moment d’afficher le menu, jamais au moment de traiter la requête. Le test doit couvrir les verbes d’écriture autant que de lecture : lire la fiche d’un tiers est grave, la modifier l’est davantage.
3. L’exploitabilité des journaux. Celui-ci n’est pas un test d’attaque, et c’est pourtant celui qui échoue le plus souvent. Après les deux premiers contrôles, on demande simplement à l’équipe de retrouver nos requêtes dans les journaux : qui, quand, quel objet. Si l’information n’est pas là, la question « qu’est-ce qui est parti ? » n’aura jamais de réponse le jour où elle se posera pour de bon. Sur les 19 périmètres, 11 n’ont pas pu reconstituer la séquence.
Ce que le cadre réglementaire en attend
Le RGPD impose une notification à la CNIL dans les 72 heures suivant la découverte d’une violation, et l’information des personnes concernées lorsque le risque est élevé. NIS2 ajoute, pour les entités visées, une alerte précoce sous 24 heures, une notification complète sous 72 heures et un rapport final sous un mois. Ces délais courent à compter de la connaissance de l’incident, ce qui replace le troisième contrôle au centre du sujet : sans journaux exploitables, vous notifiez sans savoir quoi.
Ces questions d’habilitation et de traçabilité rejoignent celles que se posent les équipes de développement sur leurs dépendances et leurs chaînes de livraison, documentées côté écosystème open source, ainsi que les enjeux d’outillage et d’automatisation traités côté intégration en entreprise. Pour cadrer le périmètre concerné chez vous, le point de départ reste notre page audit de périmètre NIS2, et notre méthode de test détaillée figure dans auditer la sécurité d’une API REST en 7 étapes.
Questions fréquentes
Qu’est-ce qu’une faille IDOR et pourquoi un scanner ne la détecte-t-il pas ?
Une faille IDOR — Insecure Direct Object Reference — consiste à exposer un identifiant d’objet, par exemple un numéro de dossier ou d’utilisateur dans une URL ou une réponse d’API, sans vérifier que la personne qui le demande a le droit de le consulter. Changer 1042 en 1043 renvoie alors la fiche du voisin. Aucun logiciel n’est vulnérable au sens classique : il n’existe ni CVE, ni correctif éditeur, ni signature à détecter. C’est précisément pour cela qu’un scanner automatique passe à côté. Un scanner sait reconnaître une version obsolète ou une injection connue ; il ne sait pas qui a le droit de voir quoi dans votre métier, parce que cette règle n’existe que dans votre application. Seul un test d’autorisation, mené avec deux comptes de niveaux différents, met ce défaut en évidence.
Combien de données ont réellement été exfiltrées au ministère de la Transition écologique ?
Les éléments publiés font état d’environ 22 800 utilisateurs répartis dans deux fichiers : un fichier controleurs.csv contenant 14 656 enregistrements et un fichier all_users.json contenant 8 166 utilisateurs. L’incident a été rendu visible le 2 septembre 2026 par l’indisponibilité de plusieurs sites du ministère, qui affichaient un message de maintenance. L’ANSSI a été mobilisée pour conduire les investigations et le ministère a déposé plainte. Ces volumes sont modestes comparés aux fuites à plusieurs millions de lignes de 2026, mais la population concernée — des agents et des contrôleurs identifiés par leur fonction — en fait un jeu de données à forte valeur pour du hameçonnage ciblé.
Une PME est-elle vraiment concernée par ce type d’attaque ?
Davantage qu’une administration, en réalité. Une faille d’autorisation n’exige ni outillage sophistiqué ni exploit acheté : un navigateur et de la patience suffisent, ce qui met l’attaque à la portée d’un très grand nombre d’acteurs. Or toute PME qui a ouvert un espace client, un portail partenaire, une application mobile ou une intégration avec un logiciel tiers expose une API, souvent sans le formuler ainsi. Le point commun de ces développements est qu’ils ont été livrés vite, que le contrôle d’accès y a été écrit au fil des écrans plutôt qu’au niveau du serveur, et que personne ne les a jamais testés avec deux comptes différents. C’est la configuration exacte qui produit une fuite de ce type.
Quelles obligations de notification s’appliquent après une fuite de ce type ?
Deux régimes se superposent. Au titre du RGPD, une violation de données à caractère personnel doit être notifiée à la CNIL dans les 72 heures suivant sa découverte, et les personnes concernées doivent être informées lorsque le risque pour leurs droits et libertés est élevé — ce qui est le cas quand la fuite comporte des identités professionnelles exploitables pour du hameçonnage. Au titre de NIS2, les entités concernées doivent adresser une alerte précoce dans les 24 heures, une notification complète sous 72 heures, puis un rapport final sous un mois. Le point pratique que retiennent trop peu d’équipes est que ces délais courent à partir de la connaissance de l’incident : sans journalisation d’accès exploitable, vous ne savez ni quand la fuite a commencé, ni ce qui est parti, et vous notifiez dans le flou.
Combien d’objets votre API rend-elle accessibles hors périmètre ?
Si la réponse n’est pas « zéro, et je peux le prouver », les trois contrôles de cet article se mènent en une demi-journée. Nous les conduisons avec vos équipes et vous laissons le jeu de tests.
Discutons-en