Le CERT-FR publie un RETEX sur les violations de données applicatives

Le CERT-FR a publié le 20 octobre 2026 un retour d'expérience de 80 pages consacré aux violations de données exploitées via des applications web : « RETEX du CERT-FR sur les violations de données applicatives » (référence CERTFR-2026-CTI-008, version 1.01). C'est le document source — le lire vaut mieux que n'importe quelle synthèse, celle-ci comprise. Il vise les responsables d'applications manipulant des données personnelles ou sensibles, et formule des constats de terrain assortis de recommandations concrètes.

Pourquoi ce document

Le CERT-FR part d'un constat opérationnel : « sur la période de la fin d'année 2025 au début 2026, de multiples incidents sur des applications contenant des données personnelles et parfois sensibles ont eu lieu », avec à la clé « la divulgation d'importantes quantités d'informations ». La plupart sont liés à des accès à des applications web opérant de grandes bases de données — exactement le profil de fuite qui a défrayé l'actualité ces derniers mois.

Le document assume ses limites : il « n'a pas vocation à traiter de façon exhaustive de la sécurité des données ni tous les scénarios de menace possibles ». C'est une liste de principes priorisés, pas un référentiel complet.

Ce qu'il recommande

Les recommandations s'articulent autour de quelques axes :

• Chiffrer les supports de stockage systématiquement, avec des clés gérées à l'état de l'art. Le CERT-FR cite explicitement LUKS + Clevis lié au TPM et un serveur Tang pour le déverrouillage distant sous Linux, et BitLocker + Network Unlock sous Windows. Les exports et sauvegardes, qui quittent l'application, doivent eux aussi être chiffrés.
• Minimiser les accès utilisateur : limiter le nombre de sessions concurrentes et la durée des sessions, poser du rate-limiting adapté au type de compte (utilisateur interactif, application tierce, client lourd, voire agent IA), et plafonner la volumétrie par session au niveau du pare-feu applicatif ou du serveur web.
• Restreindre l'exposition : filtrer l'accès aux pages et API d'administration fonctionnelle (idéalement depuis un sous-réseau dédié, avec filtrage sur l'IP source), restreindre les connexions aux heures non ouvrées (par exemple 23 h–5 h), et exiger un VPN — de préférence authentifié sur une identité de machine plutôt que d'utilisateur.
• Journaliser de façon exploitable : conserver l'adresse IP source via les en-têtes X-Forwarded-For / Forwarded / X-Real-IP, utiliser le format Syslog (RFC 5424) avec une précision à la milliseconde et des sources de temps synchronisées. Le CERT-FR note que « de nombreux attaquants y laissent des valeurs marquantes » — un user-agent de bibliothèque Python sur une connexion valide peut trahir des identifiants compromis.

Deux pistes prospectives complètent l'ensemble : le standard DBSC du W3C, qui lie les cookies à l'appareil, et des seuils de détection cumulatifs — « face à des attaquants qui travaillent sur des durées longues, on prévoira des seuils cumulatifs », au-delà des seuils instantanés que les attaquants lents contournent.

À retenir

1. Partez du document, pas des résumés. Les 80 pages détaillent la mise en œuvre technique que cet article ne fait que survoler.
2. Traitez le chiffrement des supports comme un acquis, exports et sauvegardes compris — c'est le premier axe du CERT-FR.
3. Séparez le plan d'administration des applications exposées et filtrez-le par IP source et par en-têtes, pas seulement par mot de passe.
4. Réglez vos seuils de détection avec les métiers et prévoyez une logique cumulative contre l'exfiltration lente.

Contexte

Le RETEX prolonge l'actualité française des grandes fuites applicatives sans nommer de victime : l'ANSSI capitalise sur les incidents qu'elle a accompagnés pour en extraire une doctrine réutilisable. Pour une rédaction qui couvre chaque fuite au fil de l'eau, c'est l'autre moitié du sujet — ce que les organisations auraient dû mettre en place avant d'apparaître dans la rubrique « fuite ».