Un client voit les données d’un autre : que faire en priorité

Ce que signifie qu’un client voie les données d’un autre

Si un client voit les données d’un autre, traitez‑le comme urgent. Même si ça ressemble à un bug d’interface, cela peut exposer des informations privées, briser la confiance rapidement et créer des risques juridiques ou contractuels (lois sur la vie privée, NDA, contrats d’entreprise).

« Les données d’un autre » désignent toute information appartenant à un autre utilisateur, compte ou entreprise (locataire). Cela peut apparaître dans des endroits évidents ou dans de petits détails qui permettent quand même d’identifier des personnes.

Exemples : le/la/les données d’un autre utilisateur comme :

• Nom, email, adresse ou éléments de profil
• Factures, statut de paiement, offre d’abonnement ou historique de facturation
• Messages, tickets de support ou notes internes
• Fichiers, documents ou exports (CSV/PDF)
• Vues réservées aux admins comme listes d’utilisateurs, logs d’audit ou clés API

Une distinction importante :

• Un bug d’isolation des données est un défaut produit qui renvoie ou affiche des données au mauvais locataire.
• Une fuite (breach) signifie qu’une partie non autorisée a effectivement accédé aux données (vous avez des preuves ou de forts indices que c’est le cas).

Au début, vous ne savez souvent pas lequel des deux c’est. Agissez comme si l’exposition était réelle jusqu’à preuve du contraire.

Les objectifs pratiques restent les mêmes :

1. Arrêter l’exposition rapidement (confinement).
2. Définir l’étendue (qui a vu quoi, à quelle fréquence et depuis quand).
3. Corriger la cause racine en toute sécurité.
4. Communiquer clairement pendant le travail, puis expliquer ce qui a changé.

Confinement immédiat dans les 15 premières minutes

Traitez ceci comme un incident de sécurité en direct, pas comme un ticket de bug classique. Votre première tâche est d’empêcher toute nouvelle exposition, même si vous ne comprenez pas encore la cause.

Commencez par accuser réception du signalement et ouvrez un journal d’incident. Notez l’heure exacte de la réception, qui l’a signalé, ce qu’ils ont vu (copiez leurs mots) et les captures d’écran fournies. À partir de là, horodatez chaque action et décision.

Désignez un propriétaire d’incident. Il n’a pas besoin d’écrire la correction lui‑même, mais il doit coordonner les décisions, tenir les notes et envoyer des mises à jour pour que l’équipe ne parte pas dans des directions contradictoires.

Réduisez rapidement le rayon d’impact :

• Si vous suspectez une fonctionnalité spécifique (vue admin, recherche, exports, activité récente, boîte partagée), désactivez‑la ou bloquez le endpoint.
• Si vous ne pouvez pas isoler rapidement, passez en lecture seule ou en mode maintenance pour empêcher les clients de déclencher de nouvelles requêtes susceptibles d’exposer des données.

Pendant le confinement, gèle les changements risqués. Suspendez les déploiements, migrations et jobs en arrière‑plan qui réécrivent des données. Évitez les « quick fixes » directement en production tant que vous n’avez pas une vision claire.

Une checklist simple de confinement :

• Ouvrir un journal d’incident avec horodatages et coordonnées du rapporteur
• Nommer un responsable d’incident (et un remplaçant)
• Désactiver la fonctionnalité/endpoint suspecté ou le rôle affecté
• Utiliser le mode lecture seule ou maintenance si la portée est incertaine
• Suspendre les déploiements et migrations jusqu’à confirmation du confinement

Confirmer et définir la portée sans propager le problème

Vous devez confirmer le signalement rapidement sans demander au client d’envoyer des informations plus sensibles.

Demandez le plus petit ensemble d’étapes qui a mené au problème. Demandez des actions, pas du contenu privé. Les détails utiles incluent l’heure, la page où cela est apparu et l’espace de travail/compte utilisé.

Questions qui aident généralement :

• Quelle page ou action a affiché les autres données exactement ?
• Est‑ce arrivé une seule fois, ou à chaque rafraîchissement ?
• S’en est‑il suivi d’une déconnexion/reconnexion ou d’un changement de compte/espace de travail ?
• Est‑ce que ça se produit dans un autre navigateur ou sur mobile ?
• Environ quelle quantité de données semblait incorrecte (un élément, plusieurs lignes, toute une vue de compte) ?

Reproduisez en sécurité. Utilisez un locataire de test tout neuf et un utilisateur au moindre privilège (pas un admin). Si vous avez besoin de deux locataires, créez deux comptes de test propres pour ne pas toucher aux données réelles lors des tests.

Puis vérifiez le comportement :

• Hard refresh
• Nouvelle session (mode incognito)
• Second appareil

Si le problème apparaît uniquement après un déploiement, après un changement de compte, ou uniquement pour un rôle spécifique, c’est souvent lié au caching, à la gestion des sessions ou aux frontières d’autorisation.

Considérez l’exposition comme confirmée lorsque vous pouvez la reproduire, ou quand les logs montrent des lectures inter‑locataires (même si vous ne pouvez pas encore reproduire). Considérez‑la comme suspecte si ce n’est qu’un signalement ponctuel sans preuves, mais gardez l’urgence jusqu’à ce que vous écartiez l’hypothèse.

Ce qu’il faut documenter pour pouvoir réparer et expliquer

Vos notes deviennent la colonne vertébrale de la correction et de l’explication ultérieure. Capturez le signalement tel quel avant toute paraphrase.

Enregistrez :

• Qui l’a signalé et comment le contacter
• Quand ils l’ont remarqué
• Quelle écran/fonctionnalité ils utilisaient
• Leur description exacte de ce qui semblait incorrect

Demandez des preuves avec précaution. S’ils partagent une capture d’écran, demandez‑leur de flouter les noms, emails, adresses, détails de paiement et tout ce qui n’est pas nécessaire pour vérifier le bug. Stockez les fichiers dans un dossier restreint et notez qui y a accès.

Détails techniques minimums à capturer

Vous voulez juste assez d’identifiants pour rejouer le chemin sans collecter plus de données sensibles que nécessaire.

Capturez :

• Horodatages (avec fuseau) : réception du signalement, première reproduction, confinement et chaque changement effectué
• ID de l’utilisateur rapporteur et ID du locataire/espace de travail (et l’autre ID de locataire si vous pouvez l’identifier)
• IDs de requête/correlation et identifiants de session
• Endpoints/pages affectés, filtres et paramètres de requête inhabituels
• Version de l’application ou hash de commit et heure du dernier déploiement

Récupérez des instantanés de logs tôt, car certains systèmes font de la rotation. Sauvegardez les logs d’auth, du gateway/load balancer, les logs applicatifs et les logs de requêtes DB pertinents pour la fenêtre temporelle. Notez leur origine et la durée de conservation par la source.

Tenez une timeline continue des actions de confinement (feature flags, accès désactivés, caches purgés, rollback démarré) et qui a fait chaque étape.

Triage rapide : causes racines courantes à tester en premier

La plupart des fuites inter‑locataires proviennent d’un petit ensemble de modes de défaillance. Commencez par les plus simples et avancez vers les plus subtils.

Un ordre serré de vérifications

1. Autorisation et filtrage par locataire

Recherchez des lectures qui chargent des enregistrements par id sans vérifier la propriété, ou des endpoints qui oublient d’appliquer les filtres tenant/workspace. Méfiez‑vous des chemins de type IDOR comme /invoices/123 où le serveur ne vérifie pas que l’enregistrement appartient au locataire courant.

2. Confusions de session

Vérifiez que les cookies et tokens sont correctement scindés (domaine, path, environnement). Recherchez des comptes de démonstration partagés, des clés de signature réutilisées entre environnements, ou un proxy qui supprime les en‑têtes d’auth.

3. Erreurs de mise en cache

Vérifiez les en‑têtes de cache CDN et serveur. Un Vary manquant sur les en‑têtes d’auth, ou la mise en cache de réponses HTML/API qui ne devraient jamais être partagées, peut pousser l’utilisateur A à recevoir une réponse destinée à l’utilisateur B. Inspectez aussi l’état client : le local storage obsolète peut afficher d’anciennes données après une déconnexion.

4. Bugs de requête en base de données

Revoyez les changements récents de requêtes, les jointures et les scopes par défaut. Les problèmes courants incluent des jointures qui font disparaître la contrainte de locataire, des enregistrements soft‑deleted qui réapparaissent ou des requêtes de « fallback » quand un filtre est vide.

5. Jobs en arrière‑plan et pièces jointes

Confirmez que les exports, PDFs, emails et webhooks sont construits dans le bon contexte de locataire. Les workers en file d’attente fonctionnent souvent sans les mêmes vérifications scoped à la requête.

Après chaque vérification, répondez à une question : est‑ce que les mauvaises données proviennent du serveur, ou est‑ce que l’UI affiche mal les données ? Capturer le corps et les en‑têtes de la réponse API clarifie généralement cela.

Atténuations à court terme pendant que la correction est développée

Votre objectif est d’empêcher rapidement toute nouvelle exposition, avant d’avoir la correction complète.

Réduire l’accès pendant l’investigation

Si vous suspectez des confusions de session ou de token, forcer une reconnexion propre arrête souvent la fuite.

Actions courantes à court terme :

• Révoquer les sessions actives et exiger une ré‑authentification (pour tous les utilisateurs, ou au moins pour les locataires affectés).
• Désactiver temporairement le changement de compte, l’impersonation et les fonctions « view as » admin.
• Suspendre les exports et téléchargements (CSV, PDF), et restreindre les écrans admin qui affichent beaucoup d’enregistrements.
• Mettre les pages sensibles derrière une porte de maintenance temporaire si l’isolation n’est pas fiable.
• Ajouter des limites de débit pour réduire les extractions massives pendant l’investigation.

Informez le support des changements afin qu’ils puissent expliquer les déconnexions forcées ou la suspension des exports.

Ajouter des garde‑fous temporaires

Ajoutez des vérifications côté serveur difficiles à contourner. Validez la propriété du locataire pour chaque requête, pas seulement lors du premier chargement de page.

Envisagez aussi de désactiver la mise en cache pour les endpoints et pages sensibles (y compris le cache CDN ou reverse‑proxy). Si vous ne pouvez pas la désactiver complètement, réduisez la durée de cache et assurez‑vous que la clé de cache inclut le contexte tenant et utilisateur.

Enfin, échouez fermé : si l’id du locataire est manquant, ambigu ou non conforme, renvoyez une erreur plutôt que de deviner.

Comment communiquer avec le client rapporteur

Répondez rapidement, même si vous n’avez pas encore de réponses. Le silence donne l’impression que vous ignorez un problème sérieux.

Utilisez un message calme et direct : vous avez reçu le signalement, vous le traitez en urgence et prenez des mesures pour éviter toute nouvelle exposition pendant l’investigation. N’argumentez pas, ne spéculiez pas et ne blâmez pas leur configuration.

Demandez le minimum de détails qui vous aident à reproduire :

• Quelle page ou fonctionnalité affichait les mauvaises données (et ce à quoi ils s’attendaient)
• L’heure approximative (avec fuseau)
• L’espace de travail/compte dans lequel ils étaient connectés
• Si le phénomène se répète après un rafraîchissement, une reconnexion ou dans une fenêtre privée
• Une capture d’écran avec les champs sensibles floutés (si possible et sûr)

Fixez un rythme de mise à jour réaliste. Un bon défaut : « Nous vous tiendrons informé(e) toutes les 2 à 4 heures, même si nous enquêtons toujours. »

Un message concis réutilisable :

“Merci d’avoir signalé ceci. Nous enquêtons en urgence et avons lancé des mesures de confinement pour empêcher toute nouvelle exposition. Merci de nous indiquer la page/fonctionnalité, l’heure approximative et l’espace de travail. Nous enverrons une mise à jour dans les 2 heures, puis toutes les quelques heures jusqu’à résolution.”

Quand vous avez une mitigation ou un correctif, faites un suivi en langage simple :

• Ce que vous avez trouvé
• Ce que vous avez changé (ou désactivé temporairement)
• Quelles données ont pu être visibles et pendant combien de temps (si connu)
• Ce que vous faites ensuite (monitoring, vérifications supplémentaires)

Communication interne et vers les autres clients

Choisissez un propriétaire des messages (souvent le lead d’incident). Faites transiter les mises à jour par cette personne pour que support, ventes et ingénierie ne racontent pas des histoires différentes.

Utilisez une timeline simple dans chaque mise à jour pour que chacun puisse la scanner rapidement : découvert, contenu, en cours de correction, vérification. Utilisez un seul fuseau horaire.

Soyez explicite sur ce que vous savez vs ce que vous confirmez encore. Ne devinez pas. Appuyez‑vous sur des preuves (logs, captures, endpoints spécifiques) et dites ce que vous vérifiez ensuite.

Quand vous décrivez l’impact potentiel, nommez les types de données, pas des libellés vagues comme « données personnelles ». Exemples : email de compte, nom, nom de l’entreprise, PDF de facture, 4 derniers chiffres d’une carte, adresse de livraison, texte d’un ticket de support, fichiers uploadés. N’affirmez « aucun mot de passe exposé » que si vous en avez la preuve.

Un modèle simple de mise à jour interne :

• Statut : découvert à [heure], contenu à [heure], correctif en cours, vérification en cours
• Ce qui s’est passé : 1–2 phrases
• Données potentielles impliquées : champs et écrans spécifiques
• Ce que nous savons / ce que nous confirmons : deux lignes courtes
• Prochaine mise à jour : une heure précise

Avant de notifier d’autres clients, alignez‑vous sur un déclencheur clair (par exemple : accès confirmé inter‑locataire, export/téléchargement confirmé, ou preuve que cela a duré au‑delà d’une seule session).

Scénario exemple : mélange de données de locataires après un déploiement

Un ticket de support arrive un vendredi après‑midi : un client indique qu’il a ouvert la page Factures et vu le numéro, le montant et l’adresse de facturation d’une autre société.

L’équipe traite cela comme un incident d’exposition potentiel et contient avant de déboguer :

• Ils désactivent la page Factures via un feature flag.
• Ils désactivent la couche de cache pour les réponses de factures afin d’éviter de servir des réponses mises en cache incorrectes.
• Ils révoquent les sessions actives pour les comptes ayant récemment utilisé la facturation, forçant une ré‑authentification.

Une fois contenu, ils reproduisent le problème avec deux locataires de test et consultent les logs d’accès de l’endpoint invoices. Le motif est clair : une route API renvoie des IDs de locataire mélangés, et cela n’apparaît qu’après le dernier déploiement.

Un diff du changement récent montre la cause racine. Un refactor a déplacé la logique de requête dans un helper qui n’exigeait plus tenantId, de sorte qu’un endpoint a cessé d’appliquer le filtre de locataire.

Ils publient un hotfix qui :

• Ajoute des vérifications explicites d’autorisation par locataire sur l’endpoint
• Ajoute des tests qui exécutent la même requête sur plusieurs comptes pour confirmer l’isolation
• Échoue fermé si le contexte tenant est manquant

Ils font un suivi auprès du client en langage simple : ce qui s’est passé, quelles données ont pu être visibles, ce qui l’a arrêté et ce qui empêche une répétition.

Erreurs fréquentes qui aggravent les incidents d’exposition de données

De petits choix dans la première heure peuvent augmenter l’impact et compliquer le nettoyage.

Erreur 1 : faire beaucoup de changements sans journal clair

Sous pression, on a envie d’“essayer quelques trucs” jusqu’à disparition du problème. Ensuite, on ne sait plus ce qui a aidé et on peut détruire des preuves nécessaires plus tard.

Notez chaque changement : quoi, qui, quand et pourquoi. Traitez les rollbacks, toggles de feature flag et changements de config comme des étapes formelles.

Erreur 2 : laisser fuiter des données sensibles pendant l’enquête

Les équipes support demandent parfois des captures d’écran, enregistrements d’écran ou fichiers exportés. Cela peut étendre la fuite de données.

Demandez le minimum : horodatages, nom de la page et étapes effectuées. Si une capture est inévitable, demandez au client de flouter noms, emails, tokens et tout ce qui n’est pas nécessaire pour reproduire.

Autres erreurs à éviter :

• Poster des mises à jour publiques avant d’avoir confirmé les bases (qui est affecté, quelles données, si l’accès est réel).
• Supposer que c’est « juste l’UI » sans vérifier que le backend applique les vérifications de locataire.
• Tester la correction avec un seul compte admin et manquer d’autres rôles ou chemins API.
• Considérer le premier signalement comme le seul cas au lieu de vérifier les logs pour des motifs similaires.

Un piège fréquent : un patch front empêche l’UI d’afficher des données mélangées, donc quelqu’un déclare le problème résolu. Plus tard, on découvre que l’API autorise toujours des lectures inter‑locataires via une requête directe. Confirmez toujours l’isolation côté serveur, pour tous les rôles et locataires.

Checklist rapide et prochaines étapes pratiques

Traitez « je vois les données d’un autre client » comme une urgence. Arrêtez d’abord l’exposition, puis rassemblez suffisamment de faits pour corriger et expliquer.

Une checklist pratique, dans l’ordre :

• Confinement (maintenant) : Désactivez la fonctionnalité/endpoint affichant les mauvaises données, désactivez le caching risqué et suspendez les déploiements/config jusqu’à confirmation du confinement.
• Portée (30–60 minutes) : Reproduisez en sécurité (comptes de test), identifiez les écrans/APIs affectés et estimez la fenêtre temporelle (depuis le dernier déploiement/migration/changement de config).
• Préserver les preuves : Sauvegardez les IDs de requête, horodatages, IDs utilisateur et locataire, et les logs pertinents. Floutez les captures avant de les partager en interne.
• Corriger en sécurité : Ajoutez des vérifications explicites de locataire, corrigez les clés de cache et ajoutez des tests automatisés qui échouent si les frontières de locataire sont franchies.
• Communiquer : Accusez réception du signalement, respectez un rythme de mises à jour que vous pouvez tenir, et documentez ce qui s’est passé, qui a été affecté et ce qui a changé.

Tenez un seul document d’incident dès la minute 1. Incluez qui l’a remarqué, comment vous l’avez contenu, ce que les logs montrent et le commit ou changement de config exact qui a corrigé le problème.

Si vous traitez un prototype généré par IA difficile à faire confiance sous pression (surtout autour de l’auth, des vérifications de locataire et du caching), FixMyMess (fixmymess.ai) peut réaliser un audit de code gratuit pour localiser le bug d’isolation et aider à réparer et durcir l’application rapidement, la plupart des projets étant menés en 48–72 heures.