Résumé

  • Le guide public du système électoral ouvert de LACNIC décrit une requête GET authentifiée dont le chemin contient l’adresse utilisée pour rechercher les participations d’une personne.
  • L’implémentation examinée vérifie les droits avant de renvoyer les données, mais elle reçoit l’identifiant avant cette décision et peut l’exposer aux journaux, proxys, traces et outils d’assistance.
  • Rien dans les éléments consultés ne prouve la version déployée, la présence de l’endpoint en production, une politique de journalisation particulière, une divulgation ou un préjudice.
  • Le contrat devrait transporter l’identifiant dans le contenu d’une requête ou employer un jeton opaque éphémère, avec un reçu de minimisation couvrant toute la chaîne d’observabilité.

Le contrôle d’accès arrive une étape trop tard pour le chemin

On évalue volontiers un service sensible en regardant sa serrure. Qui possède un jeton ? Quel rôle est exigé ? Une adresse réseau est-elle autorisée ? La réponse est-elle refusée lorsque l’un de ces contrôles échoue ? Ces questions sont indispensables. Elles ne disent pourtant pas ce qu’il advient du nom inscrit sur la demande avant que la serrure ne se ferme.

La page publique des élections de LACNIC renvoie vers la documentation de son projet électoral open source. Au commit retenu pour l’examen, le guide des services présente un endpoint GET paginé : electionsParticipationsByEmail/{email}/{pageSize}/{offset}. L’exemple insère dans le chemin une adresse appartenant au domaine réservé à la documentation. Le résultat annoncé est une liste de rapports de participation électorale correspondant à l’adresse, avec l’élection, le rôle et les informations associées lorsqu’elles existent.

Le code Java suit le même contrat. Il lie email à un paramètre de chemin, valide la pagination, appelle le mécanisme partagé d’authentification, puis lance la recherche de participations. Le guide de sécurité affirme qu’aucun endpoint REST de cet ensemble n’est anonyme. Dans le mode APP, un appel général doit présenter la valeur d’autorisation attendue et provenir d’une adresse IP admise. Dans le mode centralisé, le rôle api-Elections est requis. L’échec se traduit par un statut 401.

Il faut reconnaître la portée de ces mesures. Elles peuvent empêcher un tiers non autorisé d’obtenir le relevé. Elles peuvent réduire fortement la population des appelants. Le code ne décrit pas un annuaire public sans contrôle.

Il décrit néanmoins une séquence dans laquelle l’identifiant personnel est déjà entré dans la cible HTTP lorsque l’authentification commence. Un répartiteur de charge, un proxy inverse ou une passerelle a pu le traiter. Le serveur peut journaliser la requête refusée. Un agent APM peut attacher l’URI à une trace réussie. Le pare-feu applicatif peut l’ajouter à une alerte. Une exception peut partir vers un service tiers avec le contexte de la requête. L’équipe d’assistance peut recopier l’adresse affichée dans une console.

La réponse peut donc rester derrière une porte solide tandis que le nom de la personne circule sur les bordereaux du couloir. C’est cette frontière, et non une accusation de fuite, qui mérite une correction.

La précision qu’impose un dépôt public

Le code ouvert permet de vérifier des faits que l’on devrait autrement inférer. La page électorale de LACNIC rend le projet pertinent pour son périmètre public. Les métadonnées du dépôt et le commit figé donnent une date et un objet précis. Le README présente le logiciel comme un projet destiné à mettre en œuvre et exploiter des processus électoraux à distance. La documentation, la classe de service et le guide d’accès convergent sur la forme du endpoint et l’ordre du contrôle.

Cette convergence ne transforme pas le dépôt en miroir de la production. Elle ne révèle pas la révision actuellement exécutée, ni si le service est activé dans chaque installation. Elle ne relie pas le formulaire public de récupération de lien à cette route. Elle ne montre ni configuration de proxy, ni filtre de journaux, ni réglage de rétention, ni périmètre d’accès aux traces.

Aucune adresse réelle, aucun jeton, aucun identifiant d’organisation n’a été envoyé. Aucun rapport de participation n’a été demandé. Aucun journal, historique de navigateur, cache, tableau de métriques, ticket d’assistance ou export d’incident n’a été inspecté. Il n’est donc pas possible d’affirmer qu’une donnée a été divulguée, qu’une personne a subi un dommage ou qu’une obligation juridique a été enfreinte.

Des protections locales peuvent être excellentes. TLS masque la cible aux observateurs extérieurs entre des terminaisons chiffrées correctement administrées. Le proxy peut ne conserver que le modèle de route. Les segments dynamiques peuvent être supprimés, transformés avec une clé ou jamais envoyés à la télémétrie. Les journaux peuvent être très brefs et réservés à une équipe réduite. Une passerelle peut même remplacer l’adresse avant d’atteindre l’application.

La proposition éditoriale porte sur un seuil moins spectaculaire et plus robuste : un contrat sûr par défaut doit éviter de demander à chaque exploitant de redécouvrir le même risque et de réussir la même opération de masquage dans chaque outil. Le dépôt prouve que l’identifiant se trouve dans l’URI de référence. Il ne prouve pas que toutes ses copies sont maîtrisées.

Un URI n’est pas un simple tuyau

RFC 9110 rappelle que les URI sont conçus pour être partagés, non sécurisés. Ils sont affichés et consignés par les serveurs, les proxys et les agents utilisateurs dans des endroits où des tiers peuvent les voir. Le texte déconseille donc d’y placer des informations sensibles ou personnellement identifiables.

Cette propriété vient du rôle même de l’URI. La couche de routage en a besoin pour choisir le service. Le proxy s’en sert pour appliquer une règle. Le WAF l’examine pour détecter une attaque. Le serveur le conserve pour comprendre une erreur. L’outil de performance l’agrège pour comparer des latences. La console d’assistance le montre pour reproduire une requête. Chaque copie répond à une intention opérationnelle légitime ; leur somme crée une nouvelle surface de garde.

Une adresse électronique n’est pas toujours confidentielle. Dans ce endpoint, elle n’est toutefois pas un simple moyen de contact. Elle est la clé de sélection d’un dossier de participation. Avec l’heure, le nom du service, le statut de réponse et l’appelant, même une ligne de journal sans corps peut décrire un acte portant sur une personne.

Les recommandations de journalisation d’OWASP rangent les adresses électroniques parmi les données personnelles qui peuvent exiger suppression, masquage, assainissement, hachage ou chiffrement. La fiche REST prend l’exemple plus grave des identifiants d’accès placés dans une URL, car les serveurs les enregistrent. La comparaison doit rester limitée : une adresse n’est pas un secret d’authentification. La mécanique de duplication, elle, est commune.

Il faut donc distinguer les preuves. L’authentification prouve qu’un appelant a franchi un contrôle d’identité. L’autorisation prouve qu’il peut obtenir une catégorie de résultat. TLS protège un trajet. La règle de collecte décide ce que chaque composant copie. La règle de conservation décide quand la copie disparaît. Un audit sérieux ne déduit pas les deux dernières des trois premières.

Sortir la question du chemin

RFC 9110 reconnaît le compromis historique. Lorsqu’un formulaire fabrique un URI avec une donnée potentiellement sensible, POST est souvent préférable parce que la donnée voyage dans le contenu. Cette solution gêne la mise en cache et emploie une méthode non sûre pour une opération qui, conceptuellement, ne modifie rien. GET, de son côté, exprime clairement une lecture sûre et idempotente, au prix d’un URI bavard.

Publié en juin 2026, RFC 10008 normalise la méthode HTTP QUERY. Elle est sûre et idempotente, mais place la requête dans le contenu. Le document vise précisément le problème de visibilité : les URI de requête sont plus susceptibles d’être journalisés que leur contenu.

QUERY ne rend pas les corps invisibles. Une plateforme APM peut les capturer, un diagnostic peut les recopier et une règle de débogage peut les conserver. Les clients, les passerelles, les bibliothèques Java, le WAF et les outils de test devront peut-être évoluer avant de reconnaître la méthode. Adopter le mot QUERY sans réviser l’observabilité ne ferait que déplacer la donnée.

Un POST classique peut donc rester le choix le plus réaliste. Une autre architecture consiste à échanger l’adresse contre un identifiant aléatoire à courte durée de vie. L’appelant authentifié remet l’adresse une seule fois dans un contenu protégé ; le service répond avec un handle limité à cet appelant et à ce but ; les pages, nouvelles tentatives et diagnostics suivants ne manipulent plus l’adresse brute. Ce mécanisme limite la propagation, à condition de protéger aussi l’échange initial.

Il n’existe pas de méthode universellement supérieure. Le critère est le nombre de composants ayant besoin de la valeur réelle. Si seul le service de recherche en a besoin, le contrat doit empêcher les couches précédentes et suivantes de la conserver par commodité.

Un reçu plutôt qu’une promesse

« Nos journaux sont sécurisés » n’est pas une preuve de minimisation. Un journal chiffré et bien protégé demeure une copie, avec un détenteur, une finalité et une durée. Le produit attendu est un reçu versionné qui rend ces choix vérifiables.

Il indiquerait le nom et la version de l’interface, la finalité de la recherche, le rôle autorisé et la classe d’identifiant. Il préciserait le lieu de transport — chemin, paramètres, en-tête, contenu ou handle opaque — et les intermédiaires autorisés. Pour chaque couche, il déclarerait la règle : absence de collecte, modèle de route, masquage, transformation avec clé, corrélation éphémère ou exception justifiée.

La liste devrait couvrir serveur, proxy, répartiteur, WAF, maillage, APM, métriques, erreurs, cache, historique côté client, assistance et sauvegarde. À cela s’ajoutent la rétention, les groupes d’accès, le comportement de cache et de référent, la limitation de débit, la classe du résultat, le dernier test, le responsable, la date d’expiration d’une exception et l’état de migration ou de retour arrière.

Le reçu public n’a pas à révéler une topologie sensible. Il peut publier le résultat et la date, tandis que des preuves restreintes conservent configurations et traces synthétiques. Il ne doit jamais inclure l’adresse brute. Un hachage non salé n’est pas automatiquement anonyme : une valeur stable dans un espace devinable peut rester corrélable. Un jeton de test ou une transformation secrète et limitée dans le temps est souvent plus prudent.

L’ouverture du projet rend cette amélioration observable. Les mainteneurs peuvent modifier la route, les exemples, les tests et le guide de sécurité dans le même changement. Ils peuvent déprécier l’ancien endpoint, mesurer son utilisation sans garder le segment personnel et annoncer une date d’arrêt. Les exploitants peuvent ensuite produire leur propre reçu pour les composants locaux.

La conclusion est volontairement étroite. Le code examiné met une adresse de recherche dans le chemin avant d’authentifier la demande. Il ne démontre aucune compromission. Mais une bonne gouvernance électorale ne devrait pas dépendre d’une chaîne parfaite de redactions invisibles. Elle devrait rendre inutile la plupart de ces redactions.

Sources