vendredi 25 septembre 2026

À propos

Contact

Sécurité

Chiffrer les exports de données personnelles générés par l’outil RGPD natif

L'export de données personnelles intégré à WordPress part en clair par email. Voici comment le chiffrer avant envoi, dans l'esprit des recommandations de la CNIL.

Par Clément Hadrot • 21 mars 2024 • 6 min de lecture • Aucun commentaire
Chiffrer les exports de données personnelles générés par l'outil RGPD natif

Depuis WordPress 4.9.6, chaque site dispose d’un outil natif accessible depuis Réglages → Confidentialité → Exporter les données personnelles, qui permet de répondre à une demande d’exercice du droit d’accès prévu par le RGPD. L’administrateur saisit l’adresse email de la personne concernée, WordPress compile ses données (commandes, commentaires, informations de profil) dans un fichier ZIP contenant du JSON et du HTML, puis envoie un lien de téléchargement par email à la personne qui a formulé la demande.

Ce mécanisme fonctionne, mais il présente une faiblesse que peu de sites corrigent : le fichier exporté n’est jamais chiffré, et le lien de téléchargement transite par une adresse email qui peut être elle-même compromise, mal orthographiée, ou simplement lue par une autre personne que le destinataire prévu. Pour des données personnelles sensibles (historique d’achats, adresses, parfois informations de santé sur un site médical), la CNIL recommande explicitement de chiffrer tout support ou fichier contenant des données à caractère personnel avant sa transmission, particulièrement lorsqu’il transite par un canal aussi peu maîtrisé qu’une boîte email.

Comprendre le point d’accroche dans le code de WordPress

L’export de données personnelles repose sur l’action wp_privacy_personal_data_export_file, qui génère l’archive ZIP finale une fois toutes les données collectées via les exporteurs enregistrés avec le filtre wp_privacy_personal_data_exporters. C’est cette étape de génération de l’archive qu’il faut intercepter pour y ajouter un chiffrement, plutôt que de réécrire l’ensemble du mécanisme de collecte, qui fonctionne déjà correctement.

Le fichier ZIP natif est créé par la classe WP_Privacy_Data_Export_Requests_Table et la fonction utilitaire wp_privacy_generate_personal_data_export_file, qui écrit directement sur le disque dans le dossier wp-content/uploads/wp-personal-data-exports/. Ce dossier, au passage, mérite lui-même une protection par un fichier .htaccess ou une règle Nginx équivalente empêchant tout accès direct, indépendamment du chiffrement du contenu.

Ajouter un chiffrement après la génération du ZIP

L'essentiel à retenir : L'export natif produit un fichier en clair ; Un chiffrement avec un mot de passe transmis à part ; La confirmation d'identité avant tout envoi

L’approche la plus simple et la plus robuste consiste à laisser WordPress générer son ZIP normalement, puis à le rechiffrer immédiatement avec un mot de passe généré aléatoirement, avant que le lien ne soit envoyé par email. PHP dispose depuis longtemps de l’extension Sodium (intégrée nativement depuis PHP 7.2) pour ce type d’opération, mais pour rester compatible avec un simple double-clic côté utilisateur final, il est souvent préférable de passer par un ZIP chiffré avec mot de passe (AES-256), lisible par n’importe quel gestionnaire d’archives standard :

add_filter( 'wp_privacy_export_file', function( $archive_path, $request_id ) {
    $mot_de_passe = wp_generate_password( 20, false );

    $zip_chiffre = str_replace( '.zip', '-chiffre.zip', $archive_path );

    $commande = sprintf(
        'zip -j -P %s %s %s',
        escapeshellarg( $mot_de_passe ),
        escapeshellarg( $zip_chiffre ),
        escapeshellarg( $archive_path )
    );
    shell_exec( $commande );

    // On conserve le mot de passe pour l'envoyer par un canal séparé.
    update_option( 'export_pwd_' . $request_id, $mot_de_passe, false );

    // On supprime l'archive en clair, jamais laissée sur le disque.
    unlink( $archive_path );

    return $zip_chiffre;
}, 10, 2 );

Ce filtre suppose que la commande zip est disponible sur le serveur, ce qui est le cas de la grande majorité des hébergements mutualisés Linux. Sur un environnement où shell_exec est désactivé pour des raisons de sécurité, la même logique se reproduit avec l’extension PHP ZipArchive combinée à setEncryptionName, disponible depuis PHP 7.2 avec libzip.

Transmettre le mot de passe par un canal distinct

Chiffrer le fichier ne sert à rien si le mot de passe voyage dans le même email que le lien de téléchargement : un attaquant ayant intercepté la boîte mail obtiendrait les deux d’un coup. Il faut donc rompre l’unicité du canal, en s’appuyant sur une information que WordPress connaît déjà sur l’utilisateur au moment de la demande :

  • Envoyer le lien de téléchargement par email, comme le fait déjà WordPress nativement.
  • Transmettre le mot de passe par SMS si un numéro de téléphone est enregistré sur le compte, via un service tiers déjà utilisé par le site.
  • À défaut, afficher le mot de passe une seule fois dans l’interface d’administration, à charge pour l’administrateur de le communiquer par téléphone à la personne concernée après avoir vérifié son identité.

Cette dernière option est la plus simple à mettre en œuvre sans dépendance tierce, et correspond à ce que recommande la CNIL pour les demandes sensibles : une vérification d’identité renforcée avant toute transmission de données personnelles en réponse à un droit d’accès.

Nettoyer les traces après expiration

WordPress purge automatiquement les exports au bout d’un délai configurable (trois jours par défaut) via la tâche planifiée wp_privacy_delete_old_export_files. Il faut s’assurer que ce nettoyage supprime également le mot de passe stocké en option, sans quoi il reste indéfiniment en base :

add_action( 'wp_privacy_delete_old_export_files', function () {
    global $wpdb;
    $wpdb->query(
        "DELETE FROM {$wpdb->options} WHERE option_name LIKE 'export_pwd_%'"
    );
} );

Un export chiffré dont le mot de passe traîne indéfiniment en base n’a chiffré que l’apparence de la sécurité, pas le risque réel.

Ce qu’il faut retenir

Le mécanisme natif de WordPress répond à l’obligation légale d’offrir un droit d’accès aux données personnelles, mais son transport par défaut, un fichier en clair envoyé par email, ne suit pas les bonnes pratiques recommandées par la CNIL pour les données sensibles. Ajouter un chiffrement après génération de l’archive, transmettre le mot de passe par un canal distinct, et purger systématiquement les artefacts temporaires (fichier et mot de passe) sont trois ajustements simples à apporter, sans toucher au mécanisme de collecte lui-même, qui reste fiable. Pour un site traitant des catégories particulières de données (santé, données financières détaillées), ce chiffrement ne devrait pas être une option, mais un prérequis avant toute mise en production.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi