Le WordPress d'aujourd'hui, décodé pour les développeurs

Sécurité

Un PDF d’acte notarié accessible par une URL prévisible

En modifiant un seul chiffre dans une adresse, un dossier pouvait consulter l'acte notarié d'un autre dossier généré par le même site.

Par Clément Hadrot • 23 avril 2025 • 4 min de lecture • Aucun commentaire
Un PDF d'acte notarié accessible par une URL prévisible

« /actes/télécharger/4821.pdf » devient « /actes/télécharger/4822.pdf » en changeant un seul chiffre, et c’est l’acte notarié d’un tout autre dossier qui s’ouvre, sans aucune authentification demandée. C’est la découverte faite par un client d’un cabinet notarial, en modifiant par curiosité l’URL de son propre document généré après signature. Cet article ne traite pas de la génération du PDF elle-même, assurée par une extension tierce fonctionnant correctement : il se concentre sur l’absence de contrôle d’accès autour du fichier une fois produit.

Le fonctionnement du générateur de documents

Le site du cabinet reposait sur un module personnalisé qui, à la signature électronique d’un acte, générait automatiquement un PDF stocké sur le serveur et associé à un identifiant de dossier auto-incrémenté, hérité directement de l’identifiant de publication WordPress. Le lien envoyé par e-mail au client pointait vers cet identifiant, sans jeton d’accompagnement ni vérification de session.

Pourquoi la séquence numérique est un problème

L'essentiel à retenir : L'identifiant de l'acte s'incrémentait de un en un dans l'URL ; Aucune vérification de propriétaire n'était faite avant l'envoi du fichier ; Un identifiant non devinable a remplacé la séquence numérique

Un identifiant qui s’incrémente de un en un à chaque nouveau dossier transforme n’importe quel visiteur en explorateur potentiel de l’ensemble des documents du site. Il suffit de connaître son propre identifiant pour déduire la plage plausible des identifiants voisins, puis de les tester un par un ou par script. Le code du point de terminaison ne faisait aucune distinction entre le propriétaire légitime du dossier et un visiteur quelconque :

add_action('init', function () {
  if (isset($_GET['acte_id'])) {
    $id = intval($_GET['acte_id']);
    $chemin = ABSPATH . 'documents/acte-' . $id . '.pdf';
    if (file_exists($chemin)) {
      header('Content-Type: application/pdf');
      readfile($chemin);
      exit;
    }
  }
});

Aucune capacité, aucune session, aucun jeton n’intervenait dans cette logique : seul l’identifiant numérique, entièrement prévisible, contrôlait l’accès au document.

La correction en deux temps

Remplacer l’identifiant séquentiel

Chaque dossier reçoit désormais, en plus de son identifiant interne, un jeton opaque généré avec wp_generate_password(32, false) au moment de la création de l’acte, stocké en métadonnée et jamais exposé ailleurs que dans le lien envoyé au client concerné :

$jeton = wp_generate_password(32, false);
update_post_meta($id_dossier, 'jeton_acces_acte', $jeton);
$lien = home_url('/actes/telecharger/' . $jeton . '/');

Vérifier l’appartenance du document

Le point de terminaison recherche désormais le dossier par jeton, sans jamais accepter d’identifiant numérique brut, et vérifie en complément que la session en cours correspond bien à l’adresse e-mail associée au dossier avant de servir le fichier :

function servir_acte_par_jeton($jeton) {
  $dossier = get_posts(array(
    'meta_key'   => 'jeton_acces_acte',
    'meta_value' => $jeton,
    'post_type'  => 'dossier_acte',
    'numberposts' => 1,
  ));
  if (empty($dossier)) {
    wp_die('Document introuvable', 404);
  }
  // Envoi du fichier associé au dossier trouvé.
}

Un risque partagé par bien d’autres générateurs

Ce défaut ne touche pas que les actes notariés. Toute fonctionnalité qui génère un fichier après un paiement, une signature ou une inscription et qui construit son URL à partir d’un identifiant de publication est exposée au même risque : facture, certificat, attestation, relevé. Le réflexe à adopter systématiquement consiste à se demander si l’URL, une fois connue, permettrait de deviner celle d’un autre document par simple substitution d’un chiffre.

Vérifier les journaux après coup

Après correction, les journaux d’accès des semaines précédentes ont été passés en revue à la recherche de requêtes séquentielles suspectes vers l’ancien point de terminaison. Aucune preuve d’exploitation massive n’a été trouvée, mais quelques requêtes isolées, à des identifiants voisins d’un dossier réel, laissent penser qu’un client curieux avait déjà, avant l’audit, testé la faille sans nécessairement la signaler.

En résumé

Un identifiant qui s’incrémente de un en un ne doit jamais, à lui seul, contrôler l’accès à un document confidentiel. Le remplacer par un jeton opaque, combiné à une vérification de propriétaire, transforme une faille triviale à exploiter en un système où deviner une adresse valide devient statistiquement hors de portée.

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