Contrôle d'accès, comptes usurpés : les failles OWASP derrière les fuites de 2026

En avril 2026, l’Agence nationale des titres sécurisés a reconnu que les données de 11,7 millions de comptes de son portail avaient été dérobées. Le ministère de l’Intérieur n’a pas décrit la faille et renvoie aux investigations techniques, mais l’auteur présumé et plusieurs analyses relayées par la presse décrivent le même mécanisme : il suffisait de modifier un identifiant dans une requête pour obtenir les données d’un autre usager, le serveur ne vérifiant pas que le compte demandé appartenait à la personne connectée. Quatre mois plus tard, la Direction générale des Finances publiques découvrait trois intrusions successives, et l’ANSSI concluait dans son rapport d’incident que la compromission n’était « pas la conséquence d’une attaque sophistiquée » : l’attaquant s’était connecté avec des identifiants d’agents volés, sur des portails qui n’exigeaient aucune authentification multifacteur.

Si l’on s’en tient aux éléments publiés, aucune de ces deux fuites n’a demandé de faille inconnue ni d’outil élaboré. Elles relèvent de deux catégories que l’OWASP, la fondation de référence en sécurité des applications web, classe depuis des années parmi les risques les plus répandus : le contrôle d’accès défaillant et les défaillances d’authentification. Ce classement, le Top 10 de l’OWASP, est familier des développeurs et beaucoup moins des directions qui commandent, financent et réceptionnent les applications, alors que ce sont elles qui fixent les exigences, les budgets d’audit et les clauses des contrats.

Pour mesurer l’écart entre ce référentiel et la réalité des incidents, nous avons repris les 144 fiches de notre registre des fuites de données révélées entre le 1er janvier et le 7 octobre 2026, et classé chacune selon le vecteur d’attaque documenté.

Dans cet article, vous découvrirez :

• Ce qu’est l’OWASP et pourquoi son Top 10 concerne aussi les décideurs
• Les 144 fuites de 2026 classées par vecteur d’attaque, et la part dont la cause reste inconnue
• Pourquoi le contrôle d’accès reste la première faiblesse des applications
• Pourquoi un compte légitime usurpé suffit à vider une base entière
• Les exigences à poser aux équipes de développement et aux prestataires

L’OWASP, un référentiel de développeurs que les décideurs gagneraient à lire

L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie gratuitement des référentiels de sécurité applicative, élaborés par une communauté de praticiens. Le plus connu, le Top 10, classe les dix catégories de risques les plus critiques pour les applications web, à partir de données de tests portant sur plus de 2,8 millions d’applications, complétées par une enquête auprès des praticiens. Sa dernière édition, publiée fin 2025, place toujours en tête le contrôle d’accès défaillant, déjà premier en 2021. Six de ses catégories se retrouvent dans les fuites étudiées plus bas :

Code	Catégorie (édition 2025)	Ce qu’elle recouvre
A01	Contrôle d’accès défaillant	Un utilisateur accède à des données ou des fonctions qui ne lui sont pas destinées
A02	Mauvaise configuration de sécurité	Service exposé sans authentification, paramètres par défaut, environnement de test ouvert
A03	Défaillances de la chaîne d’approvisionnement logicielle	Composant tiers vulnérable ou compromis, correctif non appliqué
A05	Injection	Donnée transmise à un interpréteur sans contrôle, comme dans l’injection SQL
A07	Défaillances d’authentification	Mot de passe seul, absence de second facteur, sessions mal gérées
A09	Défaillances de journalisation et d’alerte	Activité anormale qui n’est ni enregistrée, ni signalée à temps

Le Top 10 n’est pas une norme : c’est un document de sensibilisation, qui ne se certifie pas. Deux autres projets de la fondation prolongent son usage. L’ASVS (Application Security Verification Standard) traduit ces risques en exigences vérifiables, organisées en trois niveaux selon la sensibilité de l’application, ce qui permet de les inscrire dans un cahier des charges ou un contrat. Le Top 10 de la sécurité des API, publié en 2023, décline la même logique pour les interfaces de programmation, devenues la porte d’entrée de la plupart des services en ligne.

Ces référentiels intéressent directement les directions, parce que la sécurité exigée par le RGPD s’apprécie au regard de l’état de l’art. L’article 32 impose des mesures appropriées « compte tenu de l’état des connaissances », et la CNIL renvoie elle-même à l’OWASP : sa fiche consacrée aux API recommande d’en vérifier la résistance aux risques du Top 10 des API. En décembre 2025, l’autorité a infligé une amende de 1,7 million d’euros à l’éditeur Nexpublica France, dont le logiciel permettait à des usagers de portails d’action sociale d’accéder aux documents d’autres personnes : la CNIL a estimé que ces vulnérabilités résultaient d’une méconnaissance de l’état de l’art et des principes élémentaires de sécurité, et relevé qu’elles avaient déjà été signalées par des audits antérieurs sans être corrigées.

Les 144 fuites de 2026 classées par vecteur d’attaque

Chaque fiche du registre a été rattachée à un vecteur principal, d’après ce que documentent ses sources, en distinguant le vecteur décrit officiellement, par l’organisation ou une autorité, de celui avancé par la presse spécialisée ou par l’attaquant lui-même. Les codes API4 et API6 renvoient au Top 10 des API. Une fuite peut en effet être officiellement confirmée alors que son mode opératoire ne repose que sur la revendication de son auteur.

Vecteur principal	Fiches	dont décrit officiellement	OWASP
Non communiqué	52
Compte légitime usurpé	27	14	A07, A01, A09
Compromission chez un prestataire	22	15	A03 (volet logiciel)
Vulnérabilité logicielle (injection, faille connue)	18	10	A05, A03
Contrôle d’accès défaillant (IDOR, privilèges)	15	2	A01
Rançongiciel, vecteur initial inconnu	5	1
Mauvaise configuration	4	0	A02
Aspiration massive sans limitation	1	0	API4, API6

Trois enseignements se dégagent. Le premier tient à la première ligne : pour plus d’un tiers des fuites, aucune source ne dit comment l’attaquant est entré. Les organisations notifient l’incident à la CNIL et informent les personnes concernées, mais décrivent rarement la cause en public, ce qui prive leurs pairs d’un retour d’expérience utile.

Le deuxième concerne le vecteur le mieux documenté, le compte légitime utilisé par un tiers : identifiants d’un agent, d’un conseiller, d’un médecin, d’un club ou d’un partenaire, volés puis réutilisés. C’est aussi celui que les organisations reconnaissent le plus volontiers, sans doute parce qu’il désigne une victime, l’utilisateur, plutôt qu’un défaut de leur application.

Le troisième porte sur le contrôle d’accès. Quinze fiches le désignent comme vecteur, mais deux seulement s’appuient sur une description de l’organisation concernée ; dans les autres, dont celle de l’ANTS, l’expression « faille IDOR » vient de l’attaquant ou d’analystes. Le chiffre réel est donc inconnu, et il est probablement sous-estimé, puisque ce type de défaut se cache aussi dans des fiches classées ailleurs : un compte usurpé qui exporte une base entière révèle souvent, en plus du vol d’identifiants, une absence de limite à ce que ce compte peut consulter. Quatorze fiches décrivent ainsi une aspiration automatisée, comme vecteur principal ou secondaire.

Le contrôle d’accès défaillant : quand changer un numéro suffit

Une application qui donne accès à des dossiers individuels doit répondre à deux questions distinctes. L’authentification vérifie l’identité : qui êtes-vous ? L’autorisation vérifie les droits : cet objet, ce dossier, cette facture vous appartient-il ? Les cadriciels de développement fournissent la première presque clés en main. La seconde dépend des règles métier de chaque application et doit être codée, puis testée, pour chaque type d’objet et chaque point d’accès.

Lorsque ce second contrôle manque, il suffit de remplacer le numéro de son propre dossier par un autre pour lire celui d’un tiers. L’OWASP nomme ce défaut IDOR (Insecure Direct Object Reference) ; son Top 10 des API le place en première position sous le nom de BOLA (Broken Object Level Authorization). Il échappe le plus souvent aux outils d’analyse automatique, qui ignorent que le dossier 41873 appartient à quelqu’un d’autre, et se détecte surtout en testant l’application avec plusieurs comptes de rôles différents.

Le défaut n’a rien de nouveau. Il figure sous ce nom dans le Top 10 de l’OWASP depuis l’édition de 2007, avant d’avoir été intégré en 2017 à la catégorie du contrôle d’accès, et la CNIL le sanctionne depuis 2018. En 2019, elle a infligé 180 000 euros à un courtier en assurance automobile dont il suffisait de modifier le numéro figurant en fin d’adresse pour consulter les comptes d’autres clients, en relevant que la manipulation ne demandait aucune compétence technique.

Les fiches du registre en donnent plusieurs variantes. Chez Pierre & Vacances-Center Parcs, qui a confirmé en mai l’exposition de 1,6 million de réservations, la cause évoquée par la presse est une manipulation d’identifiants sur la plateforme de réservation. Chez L’Orange bleue, l’auteur de la revendication décrit une fonction d’export accessible sans authentification ni limitation de débit, interrogée jusqu’à 200 fois par seconde ; à la Fédération française de bridge, des identifiants séquentiels et l’absence de limitation ; à Santé publique France, un compte standard capable de basculer sur un profil administrateur. Ces trois récits restent ceux des attaquants, aucune des organisations n’ayant décrit la faille.

Les cas où l’organisation documente elle-même le défaut sont plus rares et plus instructifs. Brevo a expliqué en septembre qu’un attaquant avait créé son propre compte, activé l’authentification unique (SSO), invité des utilisateurs légitimes dans cette configuration, puis s’était connecté en leur nom depuis un fournisseur d’identité qu’il contrôlait, accédant ainsi à toutes les organisations clientes auxquelles ces utilisateurs avaient accès. Le défaut ne tenait pas au mot de passe, mais à l’absence de cloisonnement entre organisations clientes.

Important : remplacer des identifiants séquentiels par des identifiants aléatoires complique l’énumération sans corriger le défaut. L’OWASP le rappelle : seul un contrôle d’autorisation côté serveur, à chaque requête, garantit que l’objet demandé appartient à l’utilisateur connecté.

Les comptes usurpés : la faille n’est pas toujours dans le code

Le rapport de l’ANSSI sur la DGFiP, publié le 29 septembre 2026, décrit précisément la chaîne qui mène d’un poste personnel infecté à l’exfiltration de données fiscales. L’attaquant a réuni, sur trois mois, plusieurs dizaines d’identifiants d’agents, probablement collectés par des infostealers sur des ordinateurs non administrés par la DGFiP. Aucune tentative de force brute n’a été observée : il disposait des mots de passe. L’absence d’authentification multifacteur sur deux portails, PIGP et ADER, lui a permis de les réutiliser immédiatement, tandis que sur un troisième portail, le code à usage unique envoyé par courriel a été contourné après la compromission du poste d’un géomètre-expert.

La suite relève de la détection. Selon l’ANSSI, 11 Go de données ont transité entre le 22 et le 25 juin sans déclencher d’alerte, le nombre de requêtes par utilisateur n’était pas surveillé, et le portail utilisé pour l’exfiltration n’était pas supervisé par le centre opérationnel de sécurité de la DGFiP. L’agence recommande d’appliquer des quotas en volume de ressources consultées, en nombre de requêtes et en volume de données échangées, et de déployer sur tous les applicatifs un second facteur « résistant à la compromission du premier ».

La CNIL fait le même constat à plus grande échelle : selon elle, près de 80 % des violations de grande ampleur qu’elle a constatées en 2024 ont été rendues possibles par l’usurpation d’un compte d’employé ou de sous-traitant protégé par un simple mot de passe. Elle a annoncé qu’elle contrôlerait dès 2026 la présence de l’authentification multifacteur sur les grandes bases de données, son absence pouvant justifier une procédure de sanction.

Le même schéma traverse les fuites les plus volumineuses du registre dont le vecteur est officiellement connu, avec un point commun : le compte détourné est le plus souvent celui d’un utilisateur métier ou d’un partenaire, rarement celui d’un administrateur.

• France Travail : des comptes de conseillers Cap emploi usurpés par ingénierie sociale, 36,8 millions de personnes concernées ; la CNIL a prononcé en janvier 2026 une amende de 5 millions d’euros, en relevant l’absence d’authentification multifacteur, une journalisation insuffisante et des habilitations trop larges.
• Cegedim : des requêtes anormales passées par les comptes de médecins utilisateurs d’un logiciel de cabinet, pour 11 à 15 millions de patients.
• Almerys : l’usurpation d’un compte donnant accès au portail de prise en charge du tiers payant, un compte « gestionnaire » selon les communiqués de mutuelles clientes, pour environ 15,4 millions de numéros de sécurité sociale.
• FFGym et FFBB : un compte de club, probablement hameçonné, ou un compte utilisateur dont le module d’éditions a été détourné, ouvrant l’outil fédéral de gestion des licences, pour 2,9 et 2 millions de licenciés.

Ces incidents relèvent d’abord des défaillances d’authentification (A07), mais pas seulement. Un conseiller, un médecin ou un club n’a besoin, pour travailler, que d’une fraction de la base ; lorsqu’un seul de ces comptes permet d’en extraire la totalité, le défaut relève aussi du contrôle d’accès (A01) et du moindre privilège, et l’absence d’alerte devant des volumes anormaux relève de la journalisation (A09). Le second facteur réduit la probabilité de l’usurpation, les plafonds et la supervision en limitent la portée.

Composants vulnérables et configurations exposées

Les vulnérabilités logicielles classiques restent présentes, mais l’année 2026 en illustre surtout la dimension collective. Huit fiches du registre renvoient à une même faille de l’outil d’analyse Metabase, une injection SQL exploitable sans authentification (CVE-2026-72898), exploitée en masse à partir d’août 2026 contre des instances internes, chez des éditeurs comme dans des administrations. Le défaut n’était pas dans le code de ces organisations, mais dans un composant qu’elles exploitaient : certaines ont été touchées avant même la publication du correctif, le 6 août, d’autres sur des instances restées sans mise à jour après cette date. L’OWASP range ce risque dans les défaillances de la chaîne d’approvisionnement logicielle (A03), qui se traitent par l’inventaire des composants et un délai de correction maîtrisé. Notre analyse de la cascade Shipup détaille comment une seule faille de ce type s’est propagée jusqu’aux clients de plusieurs enseignes.

Les mauvaises configurations (A02) apparaissent moins souvent comme vecteur principal, mais avec des volumes élevés : bases MongoDB ou Elasticsearch accessibles sans mot de passe, repérées par des chercheurs, et environnements de préproduction exposés sur Internet, comme le sous-domaine de test d’Alaxione ou le serveur de préproduction de YggTorrent selon leurs attaquants. Le risque tient moins à l’environnement de test lui-même qu’aux données réelles qu’il contient trop souvent.

Ce qu’un décideur peut exiger de ses équipes et de ses prestataires

Aucune de ces failles ne se corrige par une décision de direction. Toutes, en revanche, se préviennent mieux lorsque la direction fixe des exigences précises, les finance et vérifie qu’elles sont tenues.

Les actions prioritaires :

• Inscrire un niveau ASVS dans les contrats et les cahiers des charges. L’OWASP présente le niveau 2 comme celui que vise la plupart des applications, et l’exigence de vérifier les droits sur chaque objet figure dès le niveau 1. La fondation ne certifiant ni logiciels ni prestataires, la preuve attendue n’est pas un label mais un rapport de vérification qui précise le périmètre, les exigences contrôlées et les méthodes employées.
• Exiger des tests d’autorisation explicites dans chaque audit. Un test d’intrusion qui n’utilise qu’un seul compte ne peut pas détecter un IDOR. Le périmètre doit prévoir au moins deux comptes par rôle et par organisation cliente, et le rapport doit indiquer quels points d’accès ont été testés. Pour les systèmes sensibles, recourir à un prestataire d’audit qualifié par l’ANSSI (PASSI).
• Imposer l’authentification multifacteur à tous les accès externes, y compris ceux des partenaires, des prestataires et des agents en mobilité, avec un second facteur résistant au vol du mot de passe : une application d’authentification ou une clé physique plutôt qu’un code envoyé sur une messagerie accessible avec le même mot de passe.
• Plafonner ce que chaque compte peut extraire. Quotas par utilisateur, limitation du nombre de requêtes, alerte lorsque le volume consulté s’écarte de l’usage habituel : c’est la mesure, recommandée par l’ANSSI comme par la CNIL, qui transforme une usurpation de compte en incident mineur plutôt qu’en fuite de plusieurs millions de lignes.
• Tenir l’inventaire des composants et des environnements. Savoir quelles instances de quels logiciels tournent où, dans quelle version, et garantir que la préproduction ne contient pas de données réelles non pseudonymisées.
• Suivre la correction des audits jusqu’à leur clôture. Le cas Nexpublica montre qu’une vulnérabilité signalée et non corrigée pèse lourd dans l’appréciation de la CNIL.

Ces exigences valent aussi pour les éditeurs et prestataires, qui portent une part croissante du risque. Quelques questions suffisent à évaluer leur maturité :

Question à poser	Réponse rassurante	Signal d’alerte
Comment l’autorisation est-elle vérifiée sur chaque objet ?	Contrôle centralisé côté serveur, tests automatisés par rôle	« Les identifiants ne sont pas devinables »
Le dernier test d’intrusion a-t-il couvert le contrôle d’accès ?	Périmètre multi-comptes, rapport et plan de correction communiqués	Test limité à un scan automatique
Quel second facteur protège les comptes de vos utilisateurs et de vos équipes ?	Application d’authentification ou clé physique, imposée	Optionnel, ou code par SMS ou courriel
Un compte peut-il exporter toute la base ?	Quotas, limitation de débit, alerte sur les volumes	Aucune limite, ou pas de journalisation
Sous quel délai les correctifs critiques sont-ils appliqués ?	Délai défini et mesuré, inventaire à jour	Pas de délai ni d’inventaire

Un vocabulaire commun plutôt qu’une liste de contrôle

Le Top 10 de l’OWASP ne protège pas une application à lui seul, et cocher ses dix cases ne garantit rien. Son intérêt, pour une direction, est de fournir un vocabulaire commun avec les équipes techniques et les prestataires, et de rappeler que la plupart des fuites documentées en 2026 relèvent de catégories connues depuis longtemps : un contrôle d’autorisation absent, un mot de passe suffisant à lui seul, une extraction massive que personne ne voit passer.

Le registre montre aussi les limites de ce que l’on sait. Tant que plus d’un tiers des organisations touchées ne disent rien de la cause, et que les failles de contrôle d’accès ne sont décrites que par leurs auteurs, l’expérience des uns profite peu aux autres. Pour lire ces annonces avec le recul nécessaire, notre méthode pour distinguer une fuite alléguée d’une fuite confirmée détaille les vérifications appliquées à chaque fiche, et les définitions des termes employés ici sont réunies dans le Lexique.

Sources et références 21 sources

Référentiels OWASP

1. [1] OWASP Top 10:2025, introduction et méthodologie
2. [2] A01:2025 Broken Access Control
3. [3] A07:2025 Authentication Failures
4. [4] OWASP API Security Top 10, API1:2023 Broken Object Level Authorization
5. [5] OWASP Application Security Verification Standard (ASVS) 5.0
6. [6] OWASP Cheat Sheet : prévention des IDOR

Autorités françaises

1. [7] ANSSI : rapport d'incident sur la DGFiP, septembre 2026
2. [8] ANSSI : recommandations relatives à l'authentification multifacteur et aux mots de passe
3. [9] CNIL : consignes pour renforcer la sécurité des grandes bases de données (avril 2025)
4. [10] CNIL : fiche sécurité « API, interfaces de programmation applicative »
5. [11] CNIL : délibération SAN-2019-007 du 18 juillet 2019 (URL modifiable, 180 000 euros)
6. [12] CNIL : sanction de 1 700 000 euros à l'encontre de Nexpublica France
7. [13] CNIL : sanction de 5 millions d'euros à l'encontre de France Travail
8. [14] Assemblée nationale : réponse du Gouvernement à la question n° 727 sur l'ANTS (13 mai 2026)

Cas cités

1. [15] Fiche : ANTS / France Titres, 11,7 millions de comptes
2. [16] Fiche : DGFiP, trois intrusions reconnues
3. [17] Fiche : Pierre & Vacances-Center Parcs, 1,6 million de réservations
4. [18] Fiche : Brevo, faille du SSO SAML
5. [19] Fiche : sanction CNIL de France Travail
6. [20] Fiche : Cegedim, MonLogicielMedical
7. [21] Fiche : Almerys, plateforme de tiers payant