196 fuites web en un an : parfois sans faille zero-day

Votre extranet clients tourne depuis cinq ans. Les équipes parlent d’une « grosse refonte » l’année prochaine. En attendant, le prestataire a patché le serveur, le pare-feu est à jour, personne n’a entendu parler de CVE critique cette semaine. Pourtant, c’est souvent ainsi que les données partent : pas par une faille zero-day, mais par un compte qui fonctionne encore, une API qui renvoie trop de champs, ou un stockage accessible depuis Internet. Le 20 octobre 2026, le CERT-FR publie un retour d’expérience sur ce scénario — et les chiffres ne sont pas théoriques.

196 incidents en 2025, la complexité attaquant reste basse

Dans le rapport CERTFR-2026-CTI-008, l’ANSSI via le CERT-FR indique avoir traité 196 incidents d’exfiltration liés à des applications web en 2025, contre 130 en 2024. Aucun secteur n’est épargné. La synthèse managériale est claire : dans la plupart des cas, l’intrusion ne repose pas sur une vulnérabilité technique — réutilisation d’identifiants, ingénierie sociale, ou simple absence de contrôle d’accès sur des données exposées.

Le document illustre avec des dossiers concrets. En mai 2025, une entité e-santé voit des données personnelles et médicales extraites après prise de contrôle d’un compte utilisateur : l’attaquant interroge une API branchée sur la base. En février 2025, plusieurs acteurs agroalimentaires subissent des fuites après installation, par des salariés, d’un faux convertisseur Word→PDF qui déployait un infostealer sur les postes. Le CERT-FR rappelle aussi des exfiltrations permises par des infostealers sur des postes personnels d’usagers de services publics, ou par la compromission d’un compte prestataire sur une application de résultats médicaux.

Dix leviers sur l’existant — pas un catalogue de rêve

Le rapport n’est pas un guide exhaustif : il vise les applications web qui traitent déjà des données personnelles ou sensibles, et les mesures que les équipes du CERT-FR ont réellement déployées après incident pour limiter la récidive. Il les classe en dix pistes : politique de gestion des données, minimisation des accès utilisateur, limitation de l’exposition réseau, authentification au-delà du mot de passe, traçabilité des actions (utilisateur et adresse source), durcissement de l’hébergement, supervision des journaux, alertes et réactions automatiques en cas d’anomalie, vérification de la sécurité applicative, et — pour l’administration — homologation RGS/PSSIE. Les annexes détaillent des exemples (filtrage IP, géo-filtrage, fenêtres horaires, limitation du volume de requêtes) sur des briques vues en intervention.

Ce qu’un dirigeant peut trancher cette semaine

• Inventorier les accès réels : qui peut lire ou exporter des données clients via l’appli, l’API ou un back-office oublié — pas seulement « qui a un login ».
• Couper l’exposition inutile : ports, buckets de stockage, environnements de test copiés en prod ; le rapport cite explicitement les risques de services cloud ouverts par défaut.
• Activer une double authentification sur les comptes à privilèges et sur les interfaces d’administration — le login/mot de passe seul suffit trop souvent aux attaquants.
• Tracer et alerter : journaliser les téléchargements massifs ou les requêtes API anormales ; sans alerte, l’exfiltration ressemble à un usage légitime.
• Planifier la refonte sans reporter la sécurité : le CERT-FR dit pouvoir réduire fortement le risque sur une appli historique en attendant son remplacement — à condition de traiter ces dix axes comme un projet, pas comme une note en bas de backlog.