Sécurité offensive
Gouvernance & conformité
Protection des données
En 2025, le CERT-FR a été informé de 196 exfiltrations de données, contre 130 l’année précédente. On imagine volontiers des attaques sophistiquées derrière ces fuites. Pourtant, dans la plupart des cas, les attaquants n’ont exploité aucune faille technique : ils ont réutilisé des identifiants légitimes, obtenu un accès par ingénierie sociale ou trouvé des données exposées sans contrôle d’accès. Le centre de réponse aux incidents de l’ANSSI en tire un retour d’expérience de 80 pages, publié le 20 octobre 2026, qui décrit ce qu’il a vu chez les victimes et ce qu’il recommande pour les applications web.
Vous voulez savoir ce qu’un compte compromis permet d’extraire de votre application ? Voir nos tests d’intrusion web.
Chez Digitemis, cabinet qualifié PASSI LPM par l’ANSSI, nous menons des tests d’intrusion sur des applications web et des API qui manipulent des données personnelles. Cet article reprend les constats du CERT-FR, ses recommandations et ce qu’elles changent pour une application déjà en production.
Le périmètre du retour d’expérience
Le document s’intitule « Violations de données applicatives » et porte la référence CERTFR-2026-CTI-008. Il compte 80 pages, a été publié le 20 octobre 2026 et s’appuie sur les incidents traités par le CERT-FR de la fin 2025 au début 2026, pour la plupart sur des applications web qui opèrent de grandes bases de données. Les fuites qui partent d’un poste bureautique ou d’un environnement de développement sont volontairement laissées de côté. La violation de données y est entendue au sens de la définition de la CNIL, conforme au RGPD.
Ses recommandations n’ont pas de caractère normatif, sauf disposition réglementaire contraire. Elles sont rangées en dix principes, dont le dernier ne concerne que les administrations. Les annexes, qui occupent près du tiers du document, donnent des exemples de configuration pour les briques que le CERT-FR a croisées pendant ses interventions : Nginx, Apache, HAProxy, IIS. Le CERT-FR précise que ces produits sont cités parce qu’il les a rencontrés en réponse à incident, sans valoir recommandation d’un éditeur.
Les quatre scénarios d’accès aux données
Le CERT-FR retient quatre manières d’atteindre les données d’une application. La première est l’usurpation d’identifiants : des comptes légitimes sont utilisés par l’attaquant, qui les a obtenus par réutilisation de fuites antérieures, par ingénierie sociale ou par un logiciel espion installé sur le poste de l’utilisateur. La deuxième est l’accès direct, quand une erreur de configuration expose un port, un espace de stockage ou une sauvegarde sans passer par l’application, ce qui contourne toutes ses protections. La troisième est l’initié malveillant, en conflit avec son employeur, payé ou contraint par un attaquant, et parfois parti depuis longtemps avec un compte jamais révoqué. La quatrième est l’exploitation d’une vulnérabilité applicative, qui permet parfois de compromettre le serveur et d’aller chercher les données directement dans leur stockage.
Les cas cités par le rapport relèvent surtout des deux premiers scénarios. En mai 2025, un service de e-santé s’est fait extraire une partie de ses données personnelles et médicales : l’attaquant a pris le contrôle d’un compte utilisateur, et ce compte donnait accès à une API qui interrogeait la base de données. Dans un autre dossier traité la même année, l’API ne vérifiait pas suffisamment les droits du compte compromis, qui a servi à consulter et à extraire des données auxquelles son titulaire n’avait pas légitimement accès. Une entreprise de télétransmission de données médicales a exposé des données de patients après une erreur commise pendant une maintenance de serveur. Un laboratoire s’est fait dérober des résultats d’analyses médicales parce que le compte d’un prestataire chargé de l’application de consultation avait été compromis, sans que le laboratoire ait la moindre prise sur l’infrastructure en cause.
Les infostealers reviennent dans plusieurs dossiers. Ces logiciels malveillants récupèrent les identifiants enregistrés dans le navigateur et les cookies de session, puis les revendent, parfois sous forme d’abonnement régulièrement rafraîchi. En février 2025, plusieurs entreprises de l’agroalimentaire ont subi des violations de données après que des employés ont installé un convertisseur Word-PDF gratuit. Le logiciel exfiltrait les documents qu’on lui confiait et produisait des fichiers dont l’ouverture installait le maliciel sur un nouveau poste.
Le couple identifiant et mot de passe
Le rapport est explicite : en 2026, l’authentification par identifiant et mot de passe est obsolète, et toute application qui ne repose que sur elle doit être considérée comme exposée à un risque fort de piratage. Il distingue pourtant deux populations, parce que l’enjeu n’est pas le même. Un usager grand public n’accède en général qu’à ses propres données, et un effet de masse suppose de compromettre beaucoup de comptes. Un collaborateur interne ou un partenaire voit souvent une part importante de la base, voire sa totalité, et un seul compte compromis suffit à tout perdre.
Pour les comptes grand public, un code à usage unique demandé à chaque nouvelle session peut remplacer ou compléter le mot de passe. Il protège des attaques par dictionnaire, beaucoup moins de l’hameçonnage ciblé et de la compromission du poste, d’où la recommandation de notifier l’usager de chaque nouvelle authentification à son nom. Les passkeys, fondées sur le standard WebAuthn du W3C, offrent une protection nettement supérieure, mais elles ne fonctionnent que sur des navigateurs récents : une application qui vise un large public doit garder un parcours de repli.
Pour les comptes internes, le CERT-FR admet les codes saisis à la main comme mesure de transition, le temps de déployer mieux. Il rappelle qu’ils restent vulnérables aux attaques dites d’adversaire au milieu, où un faux site relaie la saisie de la victime en temps réel vers la vraie application. Si l’authentification forte ne peut pas être déployée rapidement, il recommande de commencer par restreindre l’accès réseau à l’application. Le rapport pointe aussi la réinitialisation de mot de passe, que beaucoup d’attaquants préfèrent à l’authentification elle-même : l’envoi d’un lien par email ne suffit plus, et chaque réinitialisation doit être tracée comme un événement de sécurité.
Le cookie de session
L’authentification ne protège que l’ouverture de session. Ensuite, chaque requête n’est plus identifiée que par un cookie, et le voler revient à récupérer l’accès tant que la session reste valide. Les marquages classiques (HttpOnly, Secure, chiffrement TLS) ne servent à rien contre un infostealer installé sur le poste ou contre un serveur mandataire offensif qui intercepte le cookie à la volée. Le CERT-FR propose deux parades : raccourcir la durée des sessions, ou lier chaque session à ses conditions d’usage (adresse IP, zone géographique, navigateur) et exiger une nouvelle authentification quand elles changent. La seconde offre, selon lui, le meilleur équilibre entre efficacité, effort et confort de l’usager, à condition de prévoir le cas des mobiles dont l’adresse change souvent. Le standard DBSC du W3C, qui lie cryptographiquement la session au composant de sécurité du poste, réglera le problème plus proprement, mais seul Google Chrome le prend en charge à la mi-2026.
Le volume accessible par compte
Le CERT-FR constate que l’usurpation d’identité est endémique. Il cherche donc à limiter ce qu’un compte compromis permet d’extraire. Moindre privilège d’abord : chaque groupe métier n’obtient que les autorisations strictement nécessaires, et un utilisateur rattaché à aucun groupe n’accède à aucune donnée. Viennent ensuite les plafonds sur le nombre de sessions simultanées, sur leur durée et sur le rythme des requêtes, adaptés au type d’accès (usager interactif, application tierce, client lourd, agent IA). La plupart des utilisateurs n’ont aucune raison de parcourir un grand nombre d’enregistrements, et le faire en peu de temps est, selon le rapport, complètement anormal.
Le rapport donne un exemple chiffré qui vaut méthode. Un secrétariat médical traite en moyenne 40 dossiers patients par jour. Une alerte peut se déclencher au-delà de 50 consultations et le compte être désactivé au-delà de 75. Ces seuils se fixent avec les métiers, puis se mesurent et s’ajustent. Il faut y ajouter des seuils cumulés sur la semaine ou le mois, parce que certains attaquants travaillent lentement. Le rapport raconte un cas où l’intrus a d’abord consulté quelques fiches à la main depuis le compte compromis, puis testé des requêtes automatisées quelques jours plus tard, avant l’extraction massive. Seule cette dernière a été repérée par la victime : les accès précédents venaient d’un compte qui avait les droits et restaient faibles en volume.
Le reste relève de la gestion des comptes. Restreindre l’accès hors des heures ouvrées quand c’est possible (le rapport cite la plage de 23 h à 5 h), désactiver les comptes inactifs, proscrire les comptes partagés et revoir les droits à chaque changement de fonction. Le CERT-FR insiste sur un point d’acceptabilité : une restriction d’accès protège aussi le titulaire du compte, sur qui la suspicion pèse longtemps quand son identité a servi à voler des données.
La traçabilité de bout en bout
Le CERT-FR dit rencontrer fréquemment ce défaut en intervention. Derrière un proxy inverse, un équilibreur de charge ou un pare-feu applicatif, l’application voit toutes les connexions arriver de l’équipement frontal, et ses journaux perdent l’adresse réelle de l’usager. La correction est généralement simple : transmettre cette adresse dans un en-tête (X-Forwarded-For ou équivalent) et de la journaliser, ce que les annexes détaillent pour chaque logiciel courant. S’y ajoutent des horodatages arrondis à la seconde et parfois sans l’année, des équipements qui ne partagent ni la même source de temps ni le même fuseau, et des actions sur les données qu’aucun journal ne permet de relier à une identité.
Les conséquences dépassent l’enquête. Le rapport décrit une remédiation qui a échoué faute de traçabilité : après un premier incident sur plusieurs entités interconnectées, les comptes compromis ont été réinitialisés, mais une application identifiait ses utilisateurs autrement et la réinitialisation ne s’y est pas appliquée. Ses données ont été exfiltrées lors d’un second incident, avec l’un des comptes compromis. Un début d’attaque qu’une équipe de supervision aurait pu contenir en quelques minutes se transforme alors en investigation de plusieurs jours.
Les journaux doivent couvrir les accès réussis et échoués, puis les consultations, ajouts, modifications et suppressions de données, avec l’utilisateur, l’adresse source, la ressource visée et la taille de l’échange. Ils sont centralisés dans un collecteur protégé, hors de portée d’un attaquant qui voudrait les effacer. Le rapport fixe six mois de conservation comme minimum dans la plupart des contextes, la durée exacte relevant d’une analyse juridique, et renvoie aux guides de l’ANSSI sur la supervision de sécurité et sur l’architecture d’un système de journalisation. Beaucoup de fuites ne sont découvertes qu’au moment où les données sont publiées, et il faut alors pouvoir remonter loin.
La réaction automatique
Le rapport part d’un constat d’échelle. Les données personnelles de millions de personnes peuvent ne peser que quelques gigaoctets, transférés en quelques minutes. La qualification d’une alerte par un humain prend des heures, la plupart des organisations n’ont personne la nuit, et les attaquants opèrent souvent en horaires décalés, avec des outils automatisés et parfois des milliers d’adresses sources différentes. Le CERT-FR recommande donc d’automatiser une partie de la riposte : ralentir les tentatives d’authentification, bloquer temporairement un compte ou une adresse, fermer l’accès aux fonctions sensibles quand une session paraît à risque.
Il précise qu’un orchestrateur de réponse (SOAR) n’est pas indispensable pour commencer. Les seuils par session se règlent sur les équipements frontaux, les ouvertures de session anormales se ralentissent dans le fournisseur d’identité, et certaines applications acceptent des règles métier en natif. Les seuils posés au niveau réseau restent un pis-aller : un attaquant les contourne en se reconnectant depuis une autre adresse, et ils ne disent ni ce qui est consulté ni par quel compte. Le rapport préfère les détections au plus près de l’application. Pour écrire les procédures d’endiguement, il renvoie aux fiches réflexes de l’InterCERT France.
Il liste aussi les situations que toute supervision devrait savoir repérer : une connexion depuis deux lieux trop éloignés pour le délai écoulé, l’énumération d’identifiants sur un champ de recherche, une taille de réponse qui s’écarte d’un tiers de la moyenne du compte, une connexion par Tor ou un VPN commercial pour un compte qui arrivait toujours d’une adresse résidentielle, un compte rattaché à une agence qui consulte soudain les données d’une autre. Le rapport note enfin que beaucoup d’attaquants ne prennent pas la peine de falsifier les en-têtes HTTP. Une connexion valide avec l’en-tête User-Agent d’une bibliothèque Python laisse penser que les identifiants du compte sont compromis.
Le cas des applications anciennes
Le message le plus utile du rapport s’adresse aux organisations qui n’ont pas les moyens de refondre leur application. Le CERT-FR rappelle que ses mesures ne remplacent pas une conception Privacy by Design. Mais il insiste sur le fait qu’on peut réduire fortement le risque sans attendre un remplacement. Quand une mesure ne peut pas s’appliquer dans le code, elle se pose souvent en amont : authentification déportée vers un fournisseur d’identité, filtrage par adresse ou par chemin sur le pare-feu applicatif, plafonds de volume sur le proxy inverse, journalisation enrichie sur le frontal. Le choix technique compte : une application qui suit une logique REST se protège facilement de l’extérieur, une application qui encode ses requêtes dans des paramètres opaques beaucoup moins.
Le rapport recommande aussi de distinguer les services par nom d’hôte plutôt que par chemin (admin.example.com plutôt que www.example.com/admin), ce qui permet d’appliquer des politiques de filtrage différentes à chacun. Il met en garde contre deux dérives. La première est le correctif virtuel posé sur un pare-feu applicatif, censé couvrir une faille le temps de la corriger, et qui devient permanent : les filtrages fondés sur un chemin ou un paramètre se contournent, et le CERT-FR a constaté plusieurs fois des mesures temporaires pérennisées sans que la faille soit jamais corrigée. La seconde est le code JavaScript qui interroge directement, depuis le navigateur, des services renvoyant des données sans authentification ni contrôle d’accès.
La vérification de la sécurité
Le neuvième principe porte sur le contrôle dans la durée. Le rapport note que, dans de nombreux incidents traités, les failles exploitées auraient pu être découvertes par des tests d’intrusion ou des audits de code. Il demande un audit avant la mise en production, puis des audits répétés, parce que les configurations évoluent, que de nouvelles vulnérabilités apparaissent dans les composants et qu’un changement d’architecture peut exposer un service prévu pour rester interne. L’exposition à Internet doit être vérifiée au minimum chaque mois et à chaque changement d’architecture, l’inventaire des composants tenu à jour (une SBOM, quand elle existe, sert de référence à la veille), et les correctifs appliqués au moins mensuellement sur les équipements les plus exposés. Pour les applications sensibles, le CERT-FR cite les audits qualifiés PASSI, sur l’architecture comme sur les vulnérabilités, comme moyen d’obtenir un avis externe et qualifié.
Plusieurs faiblesses décrites dans le rapport sont précisément celles qu’un test d’intrusion applicatif met à l’épreuve. Un compte qui lit les données d’un autre en changeant un identifiant dans une requête d’API relève du contrôle d’accès au niveau de l’objet, première famille de failles API selon l’OWASP. L’absence de plafond sur le rythme ou le volume des requêtes se vérifie en tentant une extraction. Un port d’administration resté ouvert après un débogage se trouve par un balayage externe. Le test a ses limites : il ne remplace ni la supervision des journaux ni la gestion des comptes. Il mesure en revanche, preuves à l’appui, ce qu’un compte compromis permet d’extraire de votre application.
Ce qu’il faut retenir
- Le CERT-FR a été informé de 196 exfiltrations de données en 2025, contre 130 en 2024, sans ciblage sectoriel particulier.
- La plupart ne reposent sur aucune faille technique : identifiants réutilisés ou volés, ingénierie sociale, données exposées sans contrôle d’accès.
- L’authentification par identifiant et mot de passe seuls est jugée obsolète, et les codes saisis à la main ne sont qu’une mesure de transition pour les comptes internes.
- Plafonner les sessions, le rythme et le volume des consultations limite ce qu’un compte compromis permet d’extraire.
- Une application ancienne se protège en grande partie en amont, sur les équipements frontaux, sans attendre sa refonte.
Questions fréquentes
Les recommandations du CERT-FR sont-elles obligatoires ?
Non, sauf disposition réglementaire contraire. Le dixième principe fait exception pour les entités publiques : l’homologation de sécurité de leurs systèmes d’information leur est imposée par le Référentiel général de sécurité et par le décret du 8 avril 2022, avec une analyse de risque couplée, si besoin, à une analyse d’impact (AIPD). Pour une organisation privée, le document reste une référence technique publiée par l’autorité nationale, utile pour dimensionner les mesures de sécurité qu’exige le RGPD.
Un code reçu par SMS suffit-il à protéger les comptes ?
Pour des comptes grand public, il limite les attaques par dictionnaire et par réutilisation de mots de passe. Pour des comptes internes qui accèdent à une grande partie des données, le CERT-FR ne l’admet qu’à titre transitoire, car tout code saisi à la main peut être relayé en temps réel par un faux site. Il recommande une authentification forte conforme au guide de l’ANSSI sur l’authentification multifacteur.
Faut-il refondre une application ancienne pour la sécuriser ?
Pas forcément dans l’immédiat. Le rapport montre que l’authentification, le filtrage des accès, les plafonds de volume et la journalisation peuvent souvent être ajoutés sur les composants placés devant l’application. Ces mesures réduisent le risque pendant la période, parfois longue, qui précède une refonte. Elles ne dispensent pas de planifier la correction des failles.
Combien de temps conserver les journaux applicatifs ?
Le CERT-FR retient six mois comme durée minimale dans la plupart des contextes. La durée précise dépend des obligations réglementaires et contractuelles applicables au système, et doit être fixée avec un appui juridique. La capacité de stockage doit suivre.
Où trouver le document complet ?
Le retour d’expérience est publié sur le site du CERT-FR sous la référence CERTFR-2026-CTI-008. Ses annexes contiennent des exemples de configuration directement exploitables par une équipe d’exploitation.
Pour aller plus loin
Commencez par trois vérifications qui ne coûtent que du temps. Regardez si vos journaux applicatifs contiennent l’adresse réelle des usagers ou celle de votre proxy inverse. Listez les comptes internes qui peuvent consulter une grande partie de la base avec un simple mot de passe. Demandez combien d’enregistrements un utilisateur ordinaire peut extraire en une heure sans déclencher la moindre alerte. Ces trois réponses donnent une idée assez juste de votre exposition.
Pour les chiffres des fuites en France et la question de la sous-traitance, voir notre article Fuites de données en France : ce que disent vraiment les chiffres. Pour le détail d’un audit d’API, voir Test d’intrusion mobile et API : ce que couvre vraiment un audit. Si vous voulez savoir ce qu’un compte compromis permet d’extraire de votre application, contactez-nous.
Sources
- Violations de données applicatives, retour d’expérience du CERT-FR, CERTFR-2026-CTI-008, 20 octobre 2026.
- Exfiltration de données du secteur social, retour d’expérience du CERT-FR, CERTFR-2024-CTI-009.
- L’essentiel sur les fuites de données, ANSSI.
- Recommandations relatives à l’authentification multifacteur et aux mots de passe, ANSSI.
- Violations massives de données en 2024 : quels sont les principaux enseignements ?, CNIL.
- Guide de la sécurité des données personnelles, CNIL, édition 2024.
- API1:2023 Broken Object Level Authorization, OWASP API Security Top 10.