Données sensibles et RGPD : pourquoi elles n’ont rien à faire dans ton front ?

Introduction

Récemment, une faille a fait parler d'elle sur les réseaux : l'API d'une application de rencontre renvoyait aux navigateurs les coordonnées GPS exactes de ses utilisatrices. N'importe qui sachant ouvrir les outils de développement pouvait les lire.

Ce n'est pas un cas isolé, et ce n'est pas l'histoire d'une seule personne qui a mal codé. C'est l'une des erreurs les plus courantes du développement web, et elle naît presque toujours du même raisonnement : « le front en a besoin, donc je lui envoie ».

Dans cet article, je profite de cet exemple pour t'expliquer ce qu'est une donnée sensible, pourquoi elle doit rester côté serveur, ce que dit le RGPD et ce que ça implique concrètement quand elle fuite.

Glossaire

Quelques termes à connaître pour la suite :

Terme	Définition
Frontend	Ce qui s'exécute chez l'utilisateur : navigateur, application mobile. Il est entièrement entre ses mains
Backend	Le serveur : base de données, logique métier, authentification. C'est toi qui le contrôles
API	Le point d'échange entre les deux : le front pose une question, le backend répond
Donnée personnelle	Toute information qui permet d'identifier une personne, directement ou par recoupement
Donnée sensible	Catégorie de données personnelles dont la fuite peut causer un préjudice grave (santé, orientation sexuelle, opinions...). Le RGPD parle de « catégories particulières »
RGPD	Le règlement européen qui encadre l'usage des données personnelles, en vigueur depuis 2018
Responsable de traitement	Celui qui décide pourquoi et comment les données sont collectées : une multinationale comme un développeur indépendant
Minimisation	Ne collecter et ne transmettre que ce qui est strictement nécessaire
Violation de données	Toute fuite, perte ou accès non autorisé à des données personnelles
CNIL	L'autorité française chargée de faire respecter le RGPD

C'est quoi, une donnée sensible ?

Une donnée personnelle, c'est tout ce qui permet de remonter jusqu'à quelqu'un : un nom, un email, une adresse IP, une photo. Une donnée sensible est une donnée dont la fuite peut causer un tort bien plus grave qu'un simple spam.

L'article 9 du RGPD en dresse la liste. Il interdit par principe de traiter les données qui révèlent :

• l'origine raciale ou ethnique ;
• les opinions politiques ;
• les convictions religieuses ou philosophiques ;
• l'appartenance syndicale ;
• les données génétiques et biométriques (quand elles servent à identifier une personne) ;
• les données de santé ;
• la vie sexuelle ou l'orientation sexuelle.

Traiter ces données reste possible, mais seulement dans des cas précis (le consentement explicite en est un), avec une protection renforcée.

Deux nuances importantes :

1. La géolocalisation ne figure pas dans cette liste. Mais dans les critères du G29 repris par la CNIL pour évaluer le risque d'un traitement, elle compte parmi les données sensibles ou à caractère hautement personnel.
2. Une donnée peut devenir sensible par ce qu'elle révèle. La Cour de justice de l'Union européenne a jugé en 2022 (affaire C-184/20) que des données qui dévoilent indirectement l'orientation sexuelle d'une personne relèvent aussi de l'article 9. Par le même raisonnement, s'inscrire sur une application de rencontre destinée à une orientation précise est susceptible de relever de l'article 9, avant même qu'on parle de position.

C'est exactement ce qui rend la fuite d'une position GPS dans ce type d'application si grave : on ne divulgue pas seulement un lieu, on le relie à une information intime.

Le front n'est pas à toi

Pour te l'imaginer : le front, c'est une vitrine donnée à des inconnus. Tout ce que tu y mets, ils peuvent le toucher, le photographier, l'emporter. Le backend, lui, c'est l'arrière-boutique : tu décides qui y entre.

Tout ce qui arrive dans le navigateur ou dans l'application mobile appartient à la personne qui l'utilise. Si une donnée figure dans la réponse HTTP, elle est lisible, que ton interface l'affiche ou non.

Pour la lire, pas besoin de « pirater » quoi que ce soit : l'onglet Réseau des outils de développement, un proxy comme mitmproxy ou Burp, un simple curl, ou la décompilation d'une application mobile suffisent. Masquer un champ en CSS ou ne pas l'afficher en JavaScript, c'est le cacher, pas le protéger.

D'où la règle de base : le client n'est jamais digne de confiance, et le backend est la seule frontière de sécurité. Une réponse d'API est un contrat public, on n'y met que ce dont le client a strictement besoin.

Le piège classique, c'est de renvoyer l'objet de la base tel quel (SELECT * puis res.json(user)) en se disant que le front prendra ce qu'il lui faut. L'OWASP le range dans son Top 10 des risques d'API 2023 (API3, « Broken Object Property Level Authorization »), qui reprend l'ancienne catégorie « Excessive Data Exposure ».

Pourquoi une position GPS est une donnée à part

Un mot de passe fuité se change. Une adresse, non. La position GPS cumule plusieurs propriétés qui la rendent bien plus dangereuse que la plupart des champs d'un profil :

• Elle est précise. Cinq décimales sur une latitude, c'est environ 1 mètre. Avec quatre, on est à une dizaine de mètres, avec trois à une centaine : c'est déjà un immeuble ou un pâté de maisons.
• Elle révèle les lieux de vie. Une position relevée la nuit, c'est un domicile. Une position relevée en journée en semaine, c'est un lieu de travail.
• Elle ne se révoque pas. On ne déménage pas parce qu'une base de données a fuité.
• Elle se recoupe. Associée à un prénom, une photo, un âge ou un pseudo réutilisé ailleurs, elle suffit à identifier quelqu'un.
• Elle se moissonne à grande échelle. Si une API la renvoie, un script qui boucle sur les identifiants dresse la carte de tous les utilisateurs en quelques minutes.

Un point souvent ignoré : même sans coordonnées, une distance trop précise est exploitable. Avec trois mesures de distance prises depuis trois points différents, on retrouve la position par trilatération, et en 2024, des chercheurs de la KU Leuven ont montré que six applications de rencontre (dont Bumble, Hinge et Grindr) permettaient de retrouver une position par ce type de technique. Ce que le serveur renvoie doit donc être volontairement flou.

Ce que dit le RGPD

Bonne nouvelle : tu n'as pas besoin de connaître le texte par cœur. Quelques articles suffisent à comprendre ce qu'on attend de toi quand tu développes un service qui manipule des données personnelles.

Article	Ce qu'il dit	Ce que ça change pour un développeur
5	Les données doivent être adéquates, limitées à ce qui est nécessaire (minimisation) et protégées	Ne renvoie au front que ce qu'il affiche vraiment
9	Les données sensibles sont interdites de traitement, sauf exceptions encadrées	Une base de données sensibles demande une justification et un niveau de sécurité supérieur
25	La protection des données doit être pensée dès la conception et par défaut	La liste blanche de champs par défaut, pas l'inverse
32	Il faut des mesures de sécurité adaptées au risque	Plus la donnée est sensible, plus les mesures doivent être sérieuses
33	Une violation doit être notifiée à la CNIL, si possible dans les 72 heures, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes	Prévois à l'avance qui prévient, et comment
34	Les personnes concernées doivent être informées si le risque pour elles est élevé	Une fuite de position ou d'orientation sexuelle entre clairement dans ce cadre
35	Une analyse d'impact est requise pour les traitements à risque élevé	Le traitement à grande échelle de données sensibles en fait partie (art. 35.3.b)

Côté sanctions, les manquements aux articles 25 à 39 peuvent coûter jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial, et ceux aux principes de base (articles 5 et 9 notamment) jusqu'à 20 millions ou 4 %.

Et non, la taille du projet n'y change rien : être petit ne dispense pas d'être responsable de traitement. Les critères de l'article 83 (gravité, caractère délibéré ou négligent, catégories de données concernées...) jouent sur le montant de la sanction, pas sur l'application des règles.

Ce que ça implique en cas de fuite

1. Pour les personnes

Une position exacte donne les moyens de se présenter devant chez quelqu'un. Les risques sont le harcèlement, le stalking, les violences d'un ex, et, quand la donnée est liée à une orientation sexuelle, l'outing : révéler à l'entourage, à l'employeur ou à la famille une information intime que la personne n'avait pas choisi de partager. Selon le contexte, les conséquences peuvent être graves et durables.

2. Pour le responsable du service

La fuite est une violation de données au sens du RGPD : notification à la CNIL sous 72 heures, information des personnes concernées si le risque est élevé, et exposition à des sanctions et à des réclamations. Dire si ces obligations s'appliquent à un cas précis dépend des faits, mais le réflexe doit être de se poser la question immédiatement.

3. Pour la confiance

Un service de niche vit de la confiance de sa communauté. Un incident de cette nature ne se rattrape presque jamais, surtout quand la donnée touche à l'intime.

4. Pour la suite

Corriger l'API arrête la fuite, mais ne rappelle aucune donnée déjà copiée. Tant que l'API était ouverte, il faut partir du principe que tout a pu être moissonné, et agir en conséquence : prévenir, informer, et conseiller aux personnes concernées de rester vigilantes.

Comment faire correctement

Le front n'a pas besoin de la position pour afficher « à moins de 5 km ». Il a besoin du texte « à moins de 5 km ». Le calcul se fait donc entièrement côté serveur : la position exacte est stockée, comparée, et ne sort jamais.

Le serveur renvoie un résultat volontairement grossier, arrondi par paliers :

// Backend uniquement
function distanceAffichee(metres) {
  if (metres < 1000) return "À moins de 1 km";
  const km = Math.ceil(metres / 5000) * 5;
  return `À moins de ${km} km`;
}

Et la réponse est construite par liste blanche, jamais en renvoyant l'objet de la base :

// Mauvais : la ligne de base de données part telle quelle
res.json(user);

// Bon : on déclare explicitement ce qui sort
res.json({
  id: user.publicId,
  prenom: user.prenom,
  distance: distanceAffichee(distanceEntre(moi, user)),
});

Quelques compléments qui font la différence :

• Des paliers, pas des mètres. Plus le palier est large, plus la trilatération devient inutile.
• Une liste blanche, pas une liste noire. Avec « tout sauf ces champs », le prochain champ ajouté à la table fuite par défaut.
• Des identifiants publics non devinables (UUID) plutôt que des entiers séquentiels, pour empêcher le moissonnage par énumération.
• Du rate limiting sur les recherches par proximité, et une alerte en cas d'usage anormal.
• Stocker moins de précision si le produit n'a pas besoin du mètre près.
• Un test automatisé qui échoue si un champ sensible apparaît dans une réponse d'API.

Quelle donnée peut aller au front ?

Pour te repérer, voici quelques cas courants. La règle à retenir : on envoie la forme dont le front a besoin, pas la donnée brute.

Donnée	Peut aller au front ?	Ce qu'on envoie à la place
Mot de passe ou hash	Jamais	Rien
Secret d'API, clé privée	Jamais	Rien, ces valeurs restent côté serveur
Position GPS exacte	Non	Une distance arrondie par paliers
Date de naissance	Non	L'âge
Adresse email	Seulement à son propriétaire	Rien pour les autres utilisateurs
Orientation sexuelle, santé, opinions	Seulement à son propriétaire, et si le produit en a besoin	Un indicateur minimal, jamais la donnée brute pour les autres
Pseudo, photo de profil	Oui, si la personne l'a rendu public	Tel quel
Distance arrondie	Oui	Tel quel

Conclusion

Cette faille n'est pas celle d'une personne négligente, c'est celle d'une habitude répandue : considérer l'API comme un simple tuyau entre la base de données et l'écran. Le front affiche, le backend décide. Une donnée qui n'a pas besoin de quitter le serveur n'en sort pas, et une position GPS exacte n'en a presque jamais besoin.

Quand les données touchent à l'intime (orientation, santé, localisation), le RGPD ne fait que formaliser du bon sens : en collecter le moins possible, les protéger davantage que le reste, et savoir quoi faire le jour où ça tourne mal.

Avant de fermer cet onglet, un exercice simple : ouvre l'onglet Réseau sur ton propre projet et lis chaque réponse comme le ferait quelqu'un qui n'a aucune raison de te faire confiance. Tu seras peut-être surpris.

Sources

• RGPD, articles 5 et 9 : CNIL, chapitre II
• RGPD, articles 25, 32, 33, 34 et 35 : CNIL, chapitre IV
• RGPD, article 83 (sanctions) : CNIL, chapitre VIII
• Critères de risque élevé et données de localisation : CNIL, l'analyse d'impact (AIPD)
• Arrêt de la CJUE du 1er août 2022, affaire C-184/20 : résumé du cabinet Ganado
• Trilatération sur les applications de rencontre : TechCrunch, juillet 2024
• OWASP API Security Top 10 : API3:2023