Récit d'incident : 72 heures dans une fuite de données SaaS

Le récit qui suit est composite et anonymisé, mais directement inspiré de plusieurs incidents traités en cabinet ces 18 derniers mois. Les détails techniques, les chiffres et la chronologie sont fidèles à ce qu'on observe en pratique.

Le décor

Un éditeur SaaS B2B français de 25 personnes. Deux ans d'existence, ~150 clients, une base de données utilisateurs avec ~85 000 enregistrements personnels (nom, email, entreprise, fonction, parfois numéro de téléphone). Stack standard : AWS, Node.js, Postgres, S3 pour les fichiers uploadés par les clients. Pas de données de carte (Stripe). Pas de données de santé.

L'équipe : deux fondateurs, six développeurs, un Head of Customer Success, le reste en sales et support. Aucun RSSI. Le CTO « fait la sécurité » entre deux features.

Jour 0, vendredi 18 h 47

Un développeur reçoit un email d'un chercheur en sécurité externe : « Bonjour, j'ai trouvé une exposition publique d'un endpoint d'API qui retourne des données utilisateurs sans authentification. Voici la requête. Pouvez-vous corriger ? ».

Le développeur teste. La requête fonctionne effectivement. L'endpoint, censé être un health check, prend en réalité un paramètre userId qui retourne le record complet. La cause : un if (process.env.NODE_ENV === 'production') mal placé dans un ancien commit.

Premier réflexe : couper l'endpoint. Fait à 18 h 53.

Heure 0 + 1 h, la première escalade

Le CTO est prévenu. Première discussion à trois (CTO, dev, fondateur CEO) à 19 h 30 :

Combien de temps l'endpoint a-t-il été exposé ? Inconnu pour l'instant.
Combien de records a-t-il pu retourner ? Inconnu pour l'instant.
Y a-t-il eu une exfiltration massive ? Inconnu pour l'instant.

À ce stade, trois fois inconnu est la pire situation. La tentation est de minimiser ; le bon réflexe est de partir du pire scénario possible et de l'invalider par les faits.

Le CTO active deux choses :

Fige toutes les modifications de code en production pour l'investigation.
Active les logs CloudWatch en mode détaillé sur tous les services.

Heure 0 + 4 h, les logs

À 22 h 30, l'équipe a reconstruit l'historique. Le commit fautif date de 11 mois. L'endpoint a été appelé :

Par les health checks internes : ~3 000 fois/jour (normal)
Par des bots scrapers et crawlers indéterminés : ~50 fois/mois sur les 11 mois (normal)
Par une seule IP, en 6 heures, le 17 mars : 84 712 appels avec différents userId.

Cette IP n'est pas une plage AWS connue. Reverse DNS : un VPN anonyme. Heure de l'attaque : 02 h – 08 h GMT, vraisemblablement un acteur non-européen.

Verdict : exfiltration probable de la quasi-totalité de la base utilisateurs.

Heure 0 + 12 h, samedi matin, le plan d'urgence

Le fondateur CEO appelle Cyber Experts à 7 h le samedi. Premier contact à 7 h 22. Ce qu'on déclenche dans l'heure :

Confirmation forensique, vérification que l'exfiltration ne touche pas d'autres systèmes, que l'attaquant n'a pas déposé d'accès persistant, que les sauvegardes sont intactes.
Préparation de la notification CNIL, le délai légal RGPD est de 72 h à partir de la prise de connaissance du fait. L'horloge a démarré vendredi 18 h 47.
Brouillon de communication client, structuré en trois versions : minimale (légale), équilibrée (recommandée), maximale (transparente).
Coordination avec le cabinet d'avocats du SaaS pour valider le wording.
Activation de la cyber-assurance par déclaration formelle (le SaaS en avait une, chance).

Heure 0 + 20 h, samedi soir

Décisions prises avec les fondateurs et l'avocat :

Notification CNIL en cours de rédaction, soumission visée dimanche soir
Communication client par email + bandeau in-app dimanche matin (8 h)
Soutien support renforcé prévu dès lundi 7 h
Aucune communication publique (presse, LinkedIn) avant que les clients soient prévenus

Heure 0 + 36 h, dimanche matin

Communication client envoyée à 8 h dimanche. Style adopté : la version « équilibrée ».

Bonjour,

Nous vous écrivons pour vous informer d'un incident de sécurité concernant la base utilisateurs de [SaaS]. Vendredi 18 h 47, un chercheur indépendant nous a alertés d'une exposition d'API qui pouvait retourner des données utilisateurs sans authentification. Nous avons immédiatement coupé l'accès et investigué.

Nos investigations confirment qu'un acteur tiers a probablement accédé à un volume important de données utilisateurs entre le 16 mars 02 h et 08 h. Les données concernées sont : nom, e-mail professionnel, entreprise, fonction, et éventuellement numéro de téléphone.

Aucune donnée bancaire, aucune donnée de paiement, aucun mot de passe en clair n'est concerné.

Nous avons notifié la CNIL ce week-end. Nous renforçons nos contrôles d'accès API et auditons l'ensemble de notre code source. Nous vous recommandons de rester vigilant face à des tentatives de phishing qui pourraient utiliser ces informations dans les semaines à venir.

Nous comprenons l'inquiétude que cet incident peut générer et nous nous tenons à votre disposition pour répondre à vos questions à incident@[saas].com.

Avec nos excuses sincères,

[CEO + CTO]

Réception : pas de panique. Quelques clients critiques appellent dans les heures qui suivent, satisfaits du niveau d'information. Aucun churn dans la semaine qui suit.

Heure 0 + 60 h, lundi midi

Notification CNIL soumise dimanche 22 h, accusé de réception lundi 9 h. Audit de code en cours. Deux autres endpoints découverts avec des problèmes mineurs (non exposés mais à corriger). Cyber-assureur engagé pour couvrir les coûts d'investigation.

Heure 0 + 72 h, mardi 18 h 47

Bilan à exactement 72 h :

✅ CNIL notifiée (dans les délais légaux)
✅ Clients informés
✅ Cause technique corrigée et auditée
✅ Cyber-assurance déclenchée
⏳ Forensique en cours (rapport final à J+10)
⏳ Suivi des potentielles attaques de phishing exploitant la fuite

Ce qui a sauvé l'incident

Cinq facteurs ont fait la différence :

L'alerte par un chercheur responsable plutôt que par un client. Les chercheurs externes attendent généralement un délai correct ; les clients en colère, non.
Une cyber-assurance souscrite et payée. Sans, le coût d'investigation aurait été supporté par la trésorerie.
Des logs activés et conservés. Sans logs, impossible de reconstruire la chronologie ni de qualifier l'incident.
Une chaîne de décision courte (3 personnes max). Pas de comité, pas de débat infini.
Une communication adulte plutôt que défensive. Les clients respectent l'honnêteté. Ils churn rarement quand on leur parle bien.

Ce qui aurait évité l'incident

Un audit code minimal de l'API (Upgrade, Pen-Test) aurait identifié l'endpoint vulnérable. Coût : 9 500 €. Coût total de l'incident pour ce SaaS, après assurance : ~38 000 €. Plus 6 semaines d'équipe focalisée sur cet incident au lieu de la roadmap produit.