L'essentiel en bref
Le 11 août 2026, trois cybercriminels utilisant les pseudonymes « cybernox », « artemis » et « d'ont call me » ont revendiqué avoir compromis moncoupon.santepubliquefrance.fr via une faille BOLA. Ils affirment avoir exfiltré les données de 80 000 comptes — principalement des professionnels et des structures des secteurs sanitaire, social et de la prévention. Santé publique France a confirmé l'incident le 12 août et précisé qu'aucune donnée de santé, aucune donnée bancaire et aucun mot de passe n'étaient concernés.
Au-delà de l'incident lui-même, cet événement illustre une vulnérabilité systémique dans les applications web soumises au RGPD : le contrôle d'autorisation côté serveur est encore trop souvent absent ou incomplet, en particulier sur les endpoints de modification de profil. Ce n'est pas une faille exotique — BOLA est classée numéro 1 de l'OWASP API Security Top 10 depuis 2019, et elle reste l'une des plus exploitées en 2026.
Ce qui s'est passé
Le 11 août 2026, trois pirates informatiques ont publié sur un forum spécialisé la revendication d'un accès non autorisé à moncoupon.santepubliquefrance.fr. Cette plateforme, gérée par l'agence nationale Santé publique France, permet aux professionnels de santé, aux structures sociales et aux organismes de prévention de commander gratuitement des supports de communication sanitaire (brochures, affiches, guides).
Selon les informations publiées par les cybercriminels, ils ont obtenu un accès administrateur à la fonction d'export de la base utilisateurs en manipulant une requête de modification de profil. La page de modification envoyait au serveur un champ définissant le rôle du compte ; en interceptant cette requête et en substituant le statut initial par celui d'administrateur, ils ont pu contourner les restrictions d'accès sans que le serveur ne vérifie la légitimité de cette demande d'élévation.
Santé publique France a reconnu l'incident le 12 août 2026, précisant qu'une investigation était en cours pour évaluer l'étendue exacte de la violation. L'organisme a indiqué qu'aucune donnée de santé, aucune donnée bancaire et aucun mot de passe n'étaient concernés, et que la plateforme touchée se limitait à la gestion de commandes de documents.
La faille BOLA : mécanisme et fréquence
BOLA (Broken Object Level Authorization) — ou IDOR (Insecure Direct Object Reference) dans sa formulation historique — désigne l'absence de vérification côté serveur du droit réel d'un utilisateur à accéder à un objet ou à exercer un rôle qu'il revendique dans sa requête. Dans le cas de Santé publique France, la faille portait sur le champ de rôle transmis lors de la modification de profil : le serveur acceptait la valeur fournie par le client sans vérifier indépendamment que l'utilisateur détenait effectivement ce niveau d'accès.
Ce type de vulnérabilité est particulièrement dangereux car il ne nécessite ni exploitation de faille système ni malware. Un attaquant disposant d'un compte légitime — ici, potentiellement n'importe qui pouvant créer un compte professionnel sur la plateforme — peut élever ses privilèges avec un simple outil d'interception de requêtes HTTP. La détection est difficile sans journalisation fine des actions administratives anormales.
L'OWASP classe BOLA en tête de son API Security Top 10 depuis la première édition de 2019, et la version 2023 maintient ce classement. Malgré cela, des études sectorielles estiment que plus de 40 % des applications web actives en Europe comportent au moins une instance de cette vulnérabilité — principalement sur des endpoints de modification de données personnelles ou de gestion de droits.
Les données concernées
La plateforme moncoupon.santepubliquefrance.fr collecte uniquement les informations nécessaires à la livraison des documents commandés et à l'identification professionnelle des utilisateurs. Les pirates ont publié un échantillon des données exfiltrées contenant :
- Noms et prénoms
- Adresses postales et codes postaux
- Numéros de téléphone et adresses e-mail
- Catégories professionnelles (médecin, infirmier, travailleur social, etc.)
- Noms et types de structures d'appartenance (cabinet, hôpital, EHPAD, association, etc.)
Santé publique France a explicitement confirmé que les données de santé des patients, les numéros de carte bancaire et les mots de passe ne faisaient pas partie des données exposées. Cette précision est importante : elle délimite le risque immédiat à des attaques de type hameçonnage ciblé et d'usurpation d'identité professionnelle, sans risque de compromission de dossiers médicaux ou de fraude financière directe.
La combinaison nom, adresse, téléphone, e-mail et catégorie professionnelle reste néanmoins un profil suffisant pour des campagnes de hameçonnage très personnalisées ciblant les professionnels de santé — un vecteur d'attaque particulièrement efficace dans ce secteur, où des faux messages émanant de la CNAM, de l'ARS ou de l'Assurance maladie sont déjà fréquents.
Les obligations RGPD de Santé publique France
En tant que responsable de traitement, Santé publique France est soumise aux obligations de l'article 33 du RGPD dès que la violation est constatée :
- Notification à la CNIL dans les 72 heures. Cette obligation court dès que l'organisme a connaissance de la violation, indépendamment de l'évaluation complète de son étendue. Une notification provisoire peut être déposée avec les informations disponibles, complétée ultérieurement.
- Documentation de la violation. Même si la violation n'est pas notifiée à la CNIL (ce qui n'est pas le cas ici), l'organisme doit la documenter en interne conformément à l'article 33(5). Cette documentation doit permettre à l'autorité de contrôle de vérifier le respect des obligations.
- Information des personnes concernées (article 34). Si la violation est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes — ce qui dépend de l'évaluation de l'organisme, mais que la combinaison de données exposées peut justifier — les 80 000 professionnels concernés doivent être informés directement.
L'absence de données de santé et bancaires réduit le niveau de risque par rapport à une violation portant sur des dossiers médicaux, mais la nature professionnelle détaillée des données et les risques de hameçonnage ciblé dans le secteur de la santé peuvent conduire la CNIL à qualifier le risque d'élevé et à exiger la notification aux personnes concernées.
Ce que cet incident révèle pour les équipes de développement
La faille exploitée à Santé publique France n'est pas une vulnérabilité rare ou sophistiquée. C'est une erreur de conception classique que l'on retrouve dans des applications de toutes tailles et de tous secteurs. Trois enseignements émergent de cet incident.
Premier enseignement : la confiance dans les données client est une erreur de conception. Toute valeur transmise par le client dans une requête — identifiant, rôle, statut, permission — doit être considérée comme non fiable et vérifiée indépendamment côté serveur. Ce principe de « zéro confiance côté client » est fondamental en sécurité applicative, mais son implémentation est fréquemment négligée sur les endpoints de gestion de profil ou d'administration.
Deuxième enseignement : les plateformes à vocation non commerciale ne sont pas exemptées. La plateforme moncoupon.santepubliquefrance.fr est une application de commande de documents sans enjeu financier direct. Elle ne fait pas partie des systèmes d'information les plus critiques de l'agence. Or, elle concentrait les données de contact de 80 000 professionnels de santé — une cible de valeur pour des acteurs malveillants. Toute application collectant des données personnelles est un actif à protéger, indépendamment de sa « criticité » perçue.
Troisième enseignement : les tests de sécurité doivent cibler les endpoints de gestion des droits. Les tests fonctionnels et les tests de charge ne détectent pas les failles BOLA. Seuls des tests de pénétration ciblant spécifiquement la logique d'autorisation — et idéalement intégrés à la pipeline CI/CD via des outils d'analyse de sécurité applicative statique et dynamique — peuvent détecter ces vulnérabilités avant la mise en production.
Checklist pour les équipes de développement
Ces recommandations s'appliquent à toute application web ou API exposant des données personnelles dans un contexte professionnel :
- Ne jamais exposer les champs de rôle ou de statut dans les formulaires de modification de profil sans vérification serveur. Si l'utilisateur peut modifier son propre profil, les champs définissant ses permissions ne doivent pas transiter dans la requête — ou leur valeur doit être ignorée et recalculée côté serveur à partir de la session authentifiée.
- Implémenter un contrôle d'autorisation centralisé et systématique. Chaque endpoint doit vérifier que l'utilisateur authentifié (via sa session ou son token) possède effectivement le droit d'effectuer l'action demandée sur la ressource concernée, indépendamment des valeurs transmises dans la requête.
- Journaliser les actions à privilèges élevés. Toute action administrative — export de base utilisateurs, modification de rôles, accès à des données agrégées — doit générer une entrée de journal avec identifiant de session, horodatage et scope de la requête. Ces logs sont essentiels à la détection d'anomalies et à la documentation RGPD de la violation.
- Intégrer les tests BOLA/IDOR à la pipeline CI/CD. Des outils comme OWASP ZAP, Burp Suite Pro ou des scanners DAST peuvent détecter des variantes courantes de BOLA de façon automatisée. Ces tests doivent faire partie des gates de déploiement, pas seulement des audits périodiques.
- Préparer le plan de réponse aux incidents RGPD à froid. Notification CNIL sous 72 h, évaluation du niveau de risque, modèle de communication aux personnes concernées, désignation des responsables — ce plan doit exister et avoir été testé avant que l'incident se produise. La pression d'un incident réel n'est pas le bon moment pour rédiger une procédure de notification.
Questions fréquentes
Qu'est-ce qu'une faille BOLA et pourquoi est-elle si fréquente ?
BOLA (Broken Object Level Authorization) est la vulnérabilité numéro 1 de l'OWASP API Security Top 10. Elle survient lorsqu'une application ne vérifie pas côté serveur que l'utilisateur a réellement le droit d'accéder à la ressource qu'il demande ou au rôle qu'il revendique. Elle est fréquente car la logique d'autorisation est souvent implémentée côté client ou de façon incomplète côté serveur, notamment lors des phases de modification de profil où des champs sensibles comme le rôle ou le statut sont transmis via la requête sans contrôle indépendant.
Quelles données ont été exposées dans cet incident ?
Les pirates revendiquent l'exfiltration de données de contact de 80 000 comptes : noms, adresses postales, numéros de téléphone, adresses e-mail, catégories professionnelles et noms de structures. La plateforme visée, moncoupon.santepubliquefrance.fr, gère la commande gratuite de documents de prévention santé. Santé publique France a confirmé qu'aucune donnée de santé, aucun numéro de carte bancaire et aucun mot de passe n'ont été compromis.
Santé publique France doit-elle notifier la CNIL et les personnes concernées ?
Oui. En vertu de l'article 33 du RGPD, toute violation de données personnelles doit être notifiée à la CNIL dans les 72 heures suivant sa découverte. Si la violation est susceptible d'engendrer un risque élevé pour les personnes concernées, l'article 34 impose également de les informer directement. La nature professionnelle des données et la combinaison nom, adresse, téléphone, e-mail et catégorie de structure exposent à des risques de hameçonnage ciblé et d'usurpation d'identité professionnelle.
Comment une équipe de développement peut-elle prévenir une faille BOLA ?
Trois mesures fondamentales : premièrement, valider systématiquement côté serveur que l'utilisateur authentifié possède réellement le droit qu'il revendique dans chaque requête, sans se fier aux données transmises par le client. Deuxièmement, ne jamais exposer les champs de rôle ou de statut dans les formulaires de modification de profil sans contrôle d'autorisation indépendant. Troisièmement, intégrer des tests de contrôle d'accès dans la pipeline CI/CD et réaliser des revues de sécurité applicative régulières.
Sources
SIDL Corporation — Cyberattaque contre Santé publique France : près de 80 000 personnes potentiellement exposées (12 août 2026)
Économie Matin — Piratage de Santé publique France : 80 000 Français exposés au risque de fraude
INCYBER NEWS — Fuite de données revendiquée à Santé publique France
Cyberattaque.org — Santé publique France : près de 80 000 personnes exposées après une faille