Boutique WooCommerce piratée : votre checklist de notification CNIL en 72 h

Pourquoi une boutique, ce n'est pas un site vitrine

Quand un site vitrine se fait pirater, le pire scénario habituel c'est du défacement, du spam SEO injecté, ou une redirection vers une arnaque. Désagréable, mais réversible. On nettoie, on durcit, on passe à autre chose.

Une boutique WooCommerce, c'est une base de données pleine de personnes. Dans wp_users, wp_usermeta et les tables wc_* / commandes, on trouve des noms, des adresses postales, des e-mails, des téléphones, l'historique d'achats, et selon la configuration, des fragments de données de paiement ou des identifiants vers le prestataire de paiement. Le jour où ça fuite, vous n'avez plus un problème technique : vous avez la responsabilité juridique des données d'autrui.

Sur une boutique, la vraie question après un hack n'est pas « comment je nettoie ? » mais « qu'est-ce que l'attaquant a réellement pu lire ou emporter ? » C'est cette réponse qui déclenche, ou non, vos obligations.

1. Y a-t-il vraiment eu exposition de données ?

Tout part de là. Le RGPD ne se déclenche pas parce que « le site a été piraté » dans l'absolu, mais parce que des données personnelles ont été, ou ont pu être, consultées, copiées, altérées ou détruites. Le travail de forensics consiste à transformer « on s'est fait avoir » en « voici précisément ce qui a été touché ».

• Logs d'accès (serveur web, PHP, éventuellement requêtes SQL), repérer les accès anormaux : pics de requêtes, URL d'admin inhabituelles, appels répétés à des endpoints d'export, requêtes vers /wp-admin/admin-ajax.php ou des exports CSV de commandes.
• Ce que la backdoor pouvait lire, un shell PHP avec les droits du serveur web a, en pratique, accès à wp-config.php, donc aux identifiants de la base. Partez du principe que tout ce que l'application peut lire, la backdoor le pouvait aussi.
• Les tables clients/commandes ont-elles été interrogées ou exfiltrées ?, cherchez des traces de SELECT massifs, des dumps mysqldump, des fichiers archive créés dans wp-content/uploads, des pics de trafic sortant. Une exfiltration laisse souvent un fichier temporaire et un transfert sortant.
• Skimmer JavaScript au checkout (style Magecart), le cas le plus grave et le plus discret : du JS injecté sur la page de paiement qui capture les numéros de carte côté client, avant même qu'ils n'atteignent le prestataire de paiement. La base peut sembler intacte, et pourtant des cartes fuient en direct à chaque commande.

2. Le compte à rebours de 72 heures

L'Article 33 du RGPD est clair sur le principe : dès qu'une violation susceptible d'engendrer un risque pour les droits et libertés des personnes est constatée, le responsable de traitement dispose de 72 heures pour la notifier à l'autorité de contrôle, en France, la CNIL.

Le point délicat, c'est le départ du chrono : il commence au moment où vous prenez connaissance de la violation avec un degré raisonnable de certitude qu'elle a eu lieu, pas forcément quand vous connaissez tous les détails. Vous n'avez pas besoin d'avoir fini l'enquête pour notifier ; une notification initiale, complétée ensuite, est prévue par les textes.

Concrètement, la CNIL attend que votre notification décrive :

• la nature de la violation (intrusion, backdoor, skimmer, exfiltration…) ;
• les catégories et le nombre approximatif de personnes et d'enregistrements concernés ;
• les conséquences probables pour les personnes (usurpation, hameçonnage ciblé, fraude à la carte…) ;
• les mesures prises ou envisagées pour traiter la violation et en limiter les effets.

Si vous dépassez les 72 h, ce n'est pas une fin en soi : il faut alors motiver le retard. Mais une notification tardive et non justifiée est exactement le genre de chose qui transforme un incident gérable en dossier de sanction.

3. Faut-il aussi prévenir les clients ?

C'est l'Article 34 qui entre en jeu. Quand la violation est susceptible d'engendrer un risque élevé pour les personnes, vous devez aussi les informer directement, dans les meilleurs délais, pas seulement la CNIL.

Un skimmer qui a capturé des numéros de carte, ou l'exfiltration d'une base avec e-mails + adresses + historique d'achats, coche clairement la case « risque élevé ». Les clients doivent pouvoir réagir : surveiller leurs relevés, faire opposition sur leur carte, se méfier des e-mails de hameçonnage qui suivront. L'information doit être claire, sans jargon, et indiquer quoi faire concrètement.

4. Confinement technique immédiat

En parallèle de la partie juridique, il faut stopper l'hémorragie. L'ordre des priorités change selon ce que vous trouvez, mais la logique reste : couper, isoler, assainir, sans détruire les preuves (j'y reviens à la section suivante).

• Skimmer actif ? Coupez le checkout. Tant qu'un skimmer tourne, chaque nouvelle commande fait fuiter une carte. Mettre le paiement hors-ligne (ou la boutique en maintenance) est moins coûteux qu'une cascade de fraudes.
• Rotation des secrets. Régénérez les clés et salts WordPress (les AUTH_KEY, SECURE_AUTH_KEY… de wp-config.php) pour invalider toutes les sessions, changez le mot de passe de la base, les clés d'API des prestataires de paiement et d'expédition.
• Réinitialisation forcée des mots de passe. Comptes admin d'abord, puis comptes clients si vous suspectez un accès à wp_users. Les hashs WordPress sont solides, mais un dump = une attaque hors-ligne possible.
• Supprimez la backdoor. Web shells, comptes admin fantômes, tâches cron malveillantes, fichiers .php injectés dans uploads, mu-plugins piégés. Une seule porte oubliée et tout le reste ne sert à rien.
• Nettoyez la base. Injections dans wp_options (scripts, redirections), utilisateurs ajoutés, hooks malveillants. Le mal-aimé : les payloads stockés en base réinfectent un site « nettoyé » côté fichiers.

Si je devais résumer ce volet en une phrase, ce serait : une backdoor non trouvée annule tout le nettoyage. C'est le sujet d'un autre article, mais c'est central ici aussi.

5. Préserver les preuves pour le rapport

Le réflexe de tout le monde, c'est de « tout nettoyer tout de suite ». Mauvais réflexe juridique. Avant d'écraser quoi que ce soit, faites une copie figée de l'état compromis : c'est ce qui vous permettra de qualifier la violation, de chiffrer son ampleur dans la notification, et de prouver votre bonne foi.

• Snapshot complet : fichiers + base, horodaté, avant nettoyage. Idéalement une image disque ou une archive stockée hors du serveur compromis.
• Logs bruts : serveur web, PHP, accès, et logs du pare-feu / WAF s'il y en a un. Mettez-les de côté avant qu'ils ne soient écrasés par rotation.
• Chronologie : première intrusion, date de découverte, actions menées et heure de chacune. C'est cette timeline qui justifie votre respect (ou non) des 72 h.
• Indicateurs de compromission : domaines exfiltrants, IP attaquantes, hashs des fichiers malveillants, payloads trouvés. Utiles pour le rapport et pour vérifier qu'on a tout enlevé.

La checklist 72 h, dans l'ordre

Voici la timeline que je déroule concrètement. Les phases se chevauchent un peu, mais la séquence générale est celle-ci :

H+0        DÉTECTION & CONFINEMENT
           ├─ couper le checkout si skimmer actif
           ├─ snapshot figé (fichiers + base) AVANT tout nettoyage
           ├─ mettre la boutique en maintenance si nécessaire
           └─ démarrer la chronologie (heure de découverte = départ chrono)

H+0 → H+24 FORENSICS & PÉRIMÈTRE
           ├─ analyser les logs : qu'est-ce qui a été accédé ?
           ├─ tables clients/commandes interrogées ? exfiltrées ?
           ├─ skimmer au checkout ? données carte capturées ?
           ├─ estimer : catégories + nombre de personnes / enregistrements
           └─ qualifier : risque pour les personnes ? élevé ?

H+24 → H+72 NOTIFICATION
           ├─ notifier la CNIL (Art. 33), nature, ampleur,
           │   conséquences, mesures prises
           ├─ si risque ÉLEVÉ : informer les clients (Art. 34)
           └─ notification initiale possible, complétée ensuite

APRÈS      ASSAINISSEMENT & DURCISSEMENT
           ├─ retirer toute backdoor, nettoyer la base
           ├─ rotation des clés/salts/mots de passe (terminer)
           ├─ durcir : MAJ, 2FA admin, WAF, droits fichiers
           └─ monitoring : intégrité fichiers + alertes checkout

Ce que je retiens

• Un hack e-commerce est un événement juridique, pas qu'un incident technique. Le jour où il y a des données personnelles dans la base, le RGPD s'invite à la table.
• Le forensics pilote l'obligation légale. « Qu'ont-ils réellement pu accéder ? » n'est pas une question d'orgueil technique : c'est elle qui détermine si, et quoi, vous devez notifier.
• Vitesse + documentation vous protègent. Confiner vite, prouver proprement, notifier dans les temps. Une timeline claire et des preuves figées valent mieux qu'un dossier parfait livré en retard.
• Le skimmer est l'ennemi silencieux. Il ne casse rien de visible et fait fuiter des cartes à chaque commande. Sur une boutique, c'est le premier scénario à écarter explicitement.

La leçon de fond, c'est que sur une boutique on ne « répare » pas seulement un site : on gère un incident qui engage la responsabilité d'autrui. Le bon réflexe n'est pas la panique ni le silence, c'est la méthode, et un peu d'aide quand le chrono tourne.