Fonctionnalités d'export sécurisées pour CSV et JSON sans fuites

Pourquoi les exports sont une source fréquente de fuites de données

Les exports sont l'endroit où une erreur de sécurité se transforme en fichier simple qui est partagé, transféré et stocké. Dans une application multi-tenant, un filtre manquant dans un export CSV ou JSON peut exposer les enregistrements d'un autre client en un clic. Les fonctionnalités d'export méritent la même attention que l'authentification et les paiements.

La plupart des fuites arrivent de manière banale. Une requête d'export oublie le filtre tenant. Un endpoint accepte un ID prévisible et récupère un export enregistré erroné. Un job en arrière-plan réutilise une clé de cache comme export:123 qui n'est pas liée à l'utilisateur et au tenant. Ou un ancien fichier reste dans le stockage d'objets avec une URL permanente, de sorte que quiconque le trouve peut le télécharger plus tard.

Un export sûr signifie que tout cela est vrai :

• Données correctes (la requête correspond à ce que l'UI affiche)
• Utilisateur correct (vraies permissions, pas seulement « est connecté »)
• Tenant correct (frontière stricte, pas un filtre approximatif)
• Temps correct (expire et ne peut pas être réutilisé indéfiniment)

Les gens veulent des exports rapides en un clic et des liens partageables. Des contrôles stricts ajoutent de la friction : plus de vérifications, limites de lignes, génération asynchrone et téléchargements de courte durée. L'objectif est de garder les exports pratiques sans en faire une porte dérobée autour de vos règles d'accès.

C'est aussi un mode d'échec fréquent dans les prototypes générés par l'IA. FixMyMess voit souvent des endpoints d'export qui « fonctionnent » en démo mais sautent les vérifications de permission ou stockent des fichiers d'une manière qui facilite trop les fuites inter-tenant.

Décidez ce que les utilisateurs peuvent exporter (et ce qu'ils ne peuvent pas)

Avant de construire des boutons et des endpoints, définissez ce que « export » signifie dans votre produit. Les exports sécurisés commencent par des règles claires, pas par du code.

Choisissez les formats selon les besoins réels. Le CSV est parfait pour les tableurs et l'analyse rapide, mais c'est une table plate. Le JSON est mieux pour les sauvegardes, intégrations et données imbriquées, mais il est plus facile d'y inclure par accident des champs en trop.

Définissez la portée en langage clair, puis appliquez-la en code : quels enregistrements, quelles colonnes et quelle fenêtre temporelle. Si vous ne fixez pas de limites, les utilisateurs demanderont « tout », et votre système finira par essayer de le livrer.

Notez un petit ensemble de décisions :

• Quels objets sont exportables (par exemple : factures et clients, mais pas les notes internes)
• Quels champs sont permis (et lesquels ne sont jamais exportés)
• La plage temporelle maximale par requête (par exemple « 90 derniers jours »)
• Filtres par défaut et ordre de tri pour garder des résultats prévisibles
• Qui peut exporter du tout (admins seulement, ou tous les utilisateurs)

Les champs sensibles demandent une réflexion supplémentaire. Certains doivent être exclus complètement (hashs de mots de passe, clés API). D'autres peuvent être masqués (afficher les 4 derniers chiffres). Certains peuvent nécessiter une seconde étape, comme une approbation manager ou une ré-authentification.

Exemple : un agent support peut exporter des tickets en CSV avec le nom du client et l'objet, mais pas l'email, l'IP ou les tags internes. Un admin peut exporter en JSON pour une intégration, mais seulement après avoir confirmé à nouveau son mot de passe.

Si vous avez hérité d'une app générée par l'IA, les fuites commencent souvent ici : les exports reproduisent par accident le schéma de la base. FixMyMess trouve fréquemment des champs cachés et des secrets qui glissent dans des exports « rapides », donc écrire ces règles en premier évite de travailler deux fois.

Vérifications d'accès qui correspondent aux permissions réelles

Les bugs d'export surviennent souvent lorsque l'endpoint d'export utilise des règles plus simples que les écrans de l'app. Un utilisateur peut voir une liste filtrée à l'écran, mais l'export saute discrètement ces contraintes et retourne bien plus de données. Traitez l'export comme un « chemin de lecture » à part entière, avec ses propres risques.

Vérifiez l'identité avant de construire la requête : qui est l'utilisateur, quels rôles a-t-il, et est-il un membre actif du tenant qu'il prétend représenter ? Si vous supportez des utilisateurs suspendus, des invitations expirées ou des membres supprimés, assurez-vous que ces états bloquent aussi les exports.

Séparez ensuite « peut voir dans l'app » de « peut exporter hors de l'app ». L'export est un accès en masse et inclut souvent des champs que l'on ne voit jamais à l'écran. Beaucoup d'équipes ajoutent des permissions explicites comme can_export_billing ou can_export_users et les laissent désactivées pour la plupart des rôles.

Un ensemble de règles simple qui tient la route :

• Exiger une permission explicite de bulk-export pour chaque jeu de données.
• Re-vérifier les permissions quand le job d'export s'exécute, pas seulement quand il est demandé.
• Appliquer les mêmes règles au niveau des champs que l'UI (masquer les colonnes sensibles par défaut).
• Fermer à défaut : si vous ne pouvez pas confirmer une permission, ne retournez rien.
• Garder une petite doc lisible qui mappe les rôles aux jeux de données exportables.

Exemple : un agent support peut consulter un profil client pour aider sur un ticket, mais ne peut pas exporter la liste complète des clients. Si vous autorisez l'export, restreignez-le aux rôles Admin et Billing Admin, et documentez exactement quelles tables et champs ces rôles peuvent exporter.

Si vous héritez d'un code généré par l'IA, c'est une zone où de petites discordances sont fréquentes et méritent un audit attentif.

Isolation des tenants : rendre impossible l'export d'autres tenants

Dans les produits multi-tenant, les exports sont là où l'isolation échoue souvent. Un dropdown UI peut sembler correct tandis que la requête backend retourne silencieusement des lignes d'un autre client.

La règle la plus importante : imposez le scoping tenant dans la requête elle-même, pas dans le frontend. Le backend doit déduire le tenant depuis la session authentifiée, pas depuis un paramètre de requête. Si un utilisateur peut envoyer tenant_id=other_company et que votre serveur le croit, vous avez une fuite prête à arriver.

Utilisez des règles stables qui ne changent pas par écran. Une bonne baseline : le tenant doit correspondre, et le rôle de l'utilisateur doit permettre les lignes et champs demandés. Cela signifie que votre requête d'export inclut toujours un filtre tenant plus les mêmes contraintes de permission que vous utilisez pour les écrans normaux.

Vérifications pratiques qui bloquent les exports inter-tenants :

• Prenez l'ID du tenant depuis le contexte d'auth, pas depuis le corps de la requête ou l'URL
• Ajoutez WHERE tenant_id = :tenantFromSession à chaque requête d'export
• Appliquez les règles de rôle dans la même requête (par exemple, « les agents ne peuvent exporter que les comptes qui leur sont assignés »)
• Rejetez les raccourcis « admin » sauf si l'utilisateur est vraiment admin du tenant
• Écrivez un test qui tente d'exporter un autre tenant et qui doit échouer

Si votre base de données le permet, le row-level security (RLS) ajoute une seconde serrure. Même si un futur changement de code oublie un filtre, la base de données bloque toujours les lignes qui n'appartiennent pas à ce tenant.

Exemple : un manager support exporte « tous les tickets ». Si le backend scope par tenant de session et applique les règles de rôle, l'export ne pourra jamais inclure des tickets d'une autre entreprise, même si quelqu'un édite la requête.

Si vous avez hérité d'un endpoint d'export généré par l'IA, FixMyMess trouve souvent le même bug : des vérifications tenant faites dans l'UI alors que la requête SQL n'est pas scindée. Corriger cette erreur retire la plupart des risques de fuite inter-tenant.

Limites de lignes, pagination et comportement de requête prévisible

Les exports paraissent inoffensifs jusqu'à ce que quelqu'un demande « toutes les données » et que la base passe des minutes à exécuter une requête énorme. Un export sûr a des limites claires : combien de données, dans quel ordre, et avec quels filtres.

Commencez par une limite stricte de lignes par job d'export. Choisissez un nombre que vous pouvez supporter (par exemple 50 000 lignes), appliquez-le côté serveur, et affichez la limite dans l'UI pour que les utilisateurs ne soient pas surpris. Si quelqu'un a besoin de plus, proposez de découper en exports plus petits plutôt que de générer en catimini un fichier massif.

Pour les gros jeux, ne comptez pas sur une unique requête gigantesque. Utilisez la pagination ou le découpage par dates (par exemple un fichier par mois). Cela réduit aussi les problèmes « échec à 99% » et rend les relances moins coûteuses.

Les résultats doivent être prévisibles. Appliquez toujours un ordre côté serveur (comme created_at puis id) pour que les pages ne se déplacent pas entre les requêtes. Sans ordre stable, les utilisateurs peuvent obtenir des doublons ou manquer des lignes, ce qui devient un problème support et peut même ressembler à une fuite de données.

Pour éviter que les exports ne deviennent un risque de déni de service :

• Exigez des filtres sûrs (plage de dates, statut) et rejetez les requêtes non bornées.
• Définissez des timeouts de requête et annulez les exports longue durée.
• Assurez-vous que les filtres courants sont indexés.
• Limitez la taille de page pour qu'une requête ne puisse pas tout extraire.

Exemple : si un utilisateur exporte « commandes des 30 derniers jours », vous pouvez découper par semaine, trier par created_at,id, et arrêter à la limite, donnant un résultat cohérent à chaque fois.

Étape par étape : un flux d'export simple qui reste sûr

Un export sûr consiste surtout à faire les vérifications ennuyeuses dans le bon ordre, à chaque fois. L'objectif est simple : un utilisateur ne peut exporter que ce qu'il est autorisé à voir, et seulement dans une quantité contrôlée.

Un flux pratique pour CSV et JSON :

• Accepter la requête et valider les entrées : type de fichier, plages de dates, filtres, et la permission de l'utilisateur pour les données sous-jacentes.
• Construire la requête en scoping d'abord (tenant, règles de propriété, appartenance à l'équipe), puis appliquer les filtres. Si un filtre peut changer la portée, rejetez-le.
• Décider sync vs async : les petits exports peuvent être streamés rapidement ; les plus gros devraient devenir un job en arrière-plan avec un progrès clair.
• Générer le fichier de manière défensive : utilisez une allowlist de colonnes fixe, échappez les cellules CSV qui commencent par =, +, -, @, et utilisez UTF-8.
• Retourner un handle de statut ou un token de téléchargement à courte durée, pas un fichier brut à une URL prévisible.

Exemple : un agent support exporte « Tickets des 30 derniers jours ». Même s'il essaie de changer un filtre pour un autre client, la requête est toujours épinglée à son tenant, donc l'export renverra soit ses données soit rien.

Si vous avez hérité d'une app générée par l'IA, vérifiez que les exports réutilisent le même code de permissions que l'UI, pas une « requête rapide » séparée qui saute des règles.

Génération d'export asynchrone sans casser l'expérience utilisateur

Si un export peut prendre plus que quelques secondes, rendez-le asynchrone. C'est particulièrement vrai pour les gros jeux, les requêtes lentes ou les exports qui nécessitent des transformations lourdes (joins, formatage de dates, masquage de champs). Les jobs async gardent l'app réactive et réduisent la tentation de relaxer les vérifications de sécurité juste pour accélérer les exports.

Un modèle de job simple reste compréhensible. La plupart des équipes n'ont besoin que de quelques états :

• queued (demandé, en attente d'un worker)
• running (génération en cours)
• completed (fichier prêt au téléchargement)
• failed (erreur, message sûr affiché)
• expired (trop vieux, il faut régénérer)

Les mises à jour de progression doivent être utiles sans divulguer de contenu. Au lieu d'afficher des lignes d'exemple ou des valeurs de champs, montrez des métadonnées sûres comme pourcentage accompli, lignes traitées et temps estimé.

Les retries comptent car les exports échouent pour des raisons banales : timeouts, redémarrages de DB, ou crash d'un worker. Rendez les requêtes idempotentes pour que les utilisateurs ne créent pas d'exports en double en cliquant deux fois. Un pattern pratique : calculer une clé de déduplication à partir de (tenant_id, user_id, export_type, filters, time_window) et réutiliser le même job s'il est déjà en cours.

Gardez l'UX simple :

• Affichez un badge de statut et un bouton rafraîchir, pas un spinner pour l'éternité
• Envoyez une notification quand le job est terminé
• Permettez aux utilisateurs d'annuler un export en cours
• Mettez une durée d'expiration claire sur les exports complétés

Si vous corrigez des prototypes générés par l'IA, les bugs se cachent souvent ici : filtres tenant manquants à l'intérieur du worker background. FixMyMess trouve couramment des workers qui exécutent par erreur des requêtes « admin », ce qui casse l'isolation.

Livraison sûre : des téléchargements qui ne deviennent pas des secrets partagés

Générer un export en sécurité n'est que la moitié du travail. L'autre moitié consiste à s'assurer que le fichier ne devienne pas une clé permanente et partageable que n'importe qui peut transmettre.

Une bonne pratique par défaut est de garder les fichiers d'export hors de votre base d'app principale et de les placer dans un stockage d'objets privé. Traitez le bucket comme privé, et n'autorisez les téléchargements que via des URLs signées à courte durée.

À quoi ressemble une livraison sûre :

• Utiliser des noms de fichiers longs et aléatoires (pas des IDs séquentiels comme export-123.csv) pour rendre le guessing inutile.
• Émettre un lien de téléchargement signé qui expire rapidement (minutes, pas jours).
• Lier le lien à l'utilisateur et au tenant qui a fait la demande. Si quelqu'un le transfère, la requête suivante doit échouer à moins que l'identité soit la même.
• Mettre une expiration automatique sur le fichier stocké lui-même (heures ou jours selon votre produit).
• Envisager des tokens de téléchargement à usage unique pour les exports sensibles (finance, listes d'utilisateurs, tout ce qui est régulé).

Exemple : un agent support exporte des clients pour le Tenant A, puis colle le lien dans un chat. Si votre lien est « signé pour n'importe qui », vous avez créé un secret partagé. S'il est signé pour cet agent et revérifié au moment du téléchargement, le lien transféré est inutile.

Nettoyez agressivement. Les anciens exports s'accumulent et deviennent un accident en attente d'arriver. Si vous héritez d'apps générées par l'IA où les exports sont stockés pour toujours ou exposés publiquement, FixMyMess peut auditer le chemin de livraison et le verrouiller sans réécrire tout votre produit.

Pièges CSV et JSON qui peuvent devenir des problèmes de sécurité

Les exports CSV et JSON paraissent simples, mais de petits choix de format peuvent devenir des vrais problèmes de sécurité. Beaucoup de fuites se produisent après que les données ont quitté votre app, lorsqu'on les ouvre dans Excel, qu'on les partage dans un chat ou qu'on les stocke dans le dossier de téléchargements.

CSV : le tableur fait partie de votre modèle de menace

Le CSV a un risque discret : l'injection de formules dans les tableurs. Si une cellule commence par =, +, - ou @, certaines applications tableur peuvent l'interpréter comme une formule. Un utilisateur malveillant peut mettre quelque chose comme =HYPERLINK("...") dans son champ nom, et quand un admin ouvre l'export, la formule s'exécute.

Une mitigation simple consiste à échapper ces valeurs avant d'écrire le CSV. Les approches courantes sont préfixer par une apostrophe ' ou une tabulation \t pour tout champ commençant par ces caractères.

Normalisez aussi le format pour que les exports ne cassent pas de façon surprenante. Utilisez UTF-8, quotez toujours les champs qui contiennent des virgules, des guillemets ou des sauts de ligne, et doublez les guillemets à l'intérieur d'une valeur. Sinon, les lignes peuvent se décaler, les filtres mentir, et les gens copier les mauvaises données.

JSON : facile de sur-partager

Le JSON incite à dumper l'objet entier. C'est comme ça que des tokens d'accès, clés API, hashes de reset de mot de passe, IDs internes et champs de debug glissent dans les exports. Traitez les exports comme un contrat public : construisez une allowlist explicite des champs.

Il aide aussi d'ajouter un petit bloc d'en-tête pour que le fichier s'explique lui-même :

• Heure d'export (UTC)
• Filtres appliqués (tel que l'utilisateur les a définis)
• Nombre de lignes (et si c'était tronqué)
• Périmètre des données (nom du tenant ou workspace)

Exemple : un manager support exporte Customers filtrés pour un workspace. Si le JSON contient stripeSecretKey parce qu'il vit sur le même modèle, vous venez de créer une fuite de credential portable. Les champs explicites empêchent ça.

Logs d'audit et monitoring que vous utiliserez vraiment

Les logs d'audit sont votre ceinture de sécurité pour les exports. Quand quelque chose tourne mal, vous avez besoin de réponses claires à trois questions : qui l'a fait, qu'est-ce qu'il a exporté, et où ça est allé.

Loggez l'export en deux événements : la requête et le téléchargement. La requête vous dit l'intention (et la portée). Le téléchargement confirme la livraison (et depuis quel utilisateur et IP). Gardez ça léger et cherchéable pour que vous ouvriez vraiment ces logs pendant un incident.

Capturez assez de détails pour enquêter sans stocker les données exportées elles-mêmes :

• Qui : user ID, rôle, tenant ID, et la méthode d'auth utilisée
• Quoi : nom du dataset, filtres appliqués, nombre de lignes, et colonnes incluses
• Quand/où : timestamps, IP, user agent, et job ID d'export
• Résultat : succès/échec, codes d'erreur, et taille du fichier

Le monitoring concerne les patterns, pas la perfection. Alarmez sur des choses qui arrivent rarement en travail normal : beaucoup d'exports en peu de temps, exports inhabituellement larges, échecs répétés, ou téléchargements en dehors des heures habituelles du tenant. Lieez les alertes à des actions, comme forcer temporairement des limites de lignes plus petites.

Donnez aux admins des contrôles simples de réponse : révoquer un job d'export spécifique, invalider un token de téléchargement, et raccourcir l'expiration pendant un incident. Si vous héritez d'une app générée par l'IA avec des logs manquants ou bruyants, FixMyMess peut vous aider à ajouter des pistes d'audit fiables sans refaire tout votre produit.

Erreurs courantes et pièges à éviter

La plupart des fuites d'export ne sont pas des hacks sophistiqués. Ce sont des écarts entre ce que l'UI montre et ce que le serveur applique. Traitez chaque requête d'export comme une lecture directe de base de données, parce que c'est ce qu'elle devient.

Pièges courants :

• Faire confiance aux filtres UI (comme un champ tenantId caché) au lieu d'appliquer les vérifications tenant côté serveur pour chaque requête.
• Cacher des fichiers d'export générés et servir par erreur le même fichier à un autre utilisateur ou tenant.
• Autoriser des plages de dates illimitées ou « exporter tout » sans cap strict, ce qui peut causer de grosses lectures, timeouts et partages accidentels.
• Retourner des erreurs brutes qui exposent des noms de tables, fragments SQL ou IDs internes qui aident un attaquant à deviner votre schéma.
• Copier du code d'export depuis un prototype généré par l'IA et le mettre en production sans revue de sécurité.

Un exemple réaliste : un agent support sélectionne « 90 derniers jours » dans l'UI. Le backend construit une requête seulement à partir de la plage de dates et oublie tenant_id = currentTenant. L'export « a l'air correct » pendant les tests parce que le testeur n'a qu'un tenant de données. En production, il récupère silencieusement d'autres tenants aussi.

Des garde-fous pratiques empêchent la plupart de cela :

• Construire la requête depuis le contexte serveur d'abord (utilisateur courant, rôle, tenant), puis appliquer les filtres utilisateur.
• Donner à chaque job d'export un propriétaire et un tenant unique, et vérifier les deux lors de la génération et du téléchargement.
• Mettre des limites strictes (lignes, plage de dates, taille de fichier) et exiger des filtres plus précis pour des exports plus larges.
• Normaliser les messages d'erreur pour les utilisateurs ; garder les détails dans les logs.

Si vous avez hérité de code d'exportal de Lovable, Bolt, v0, Cursor ou Replit, FixMyMess trouve souvent ces mêmes problèmes lors d'un audit rapide et aide à les patcher avant qu'ils ne deviennent un incident.

Checklist rapide avant de livrer des exports

Faites un passage rapide avec un état d'esprit sécurité avant de mettre en production les exports CSV ou JSON. La plupart des fuites d'export proviennent d'une petite hypothèse qui s'est glissée, comme faire confiance à un filtre depuis l'UI ou laisser un lien de téléchargement utilisable pour toujours.

Commencez par l'accès et la portée. Chaque requête d'export doit vérifier l'utilisateur courant, son rôle et le tenant auquel il appartient. Ensuite, vérifiez qu'il a une permission spécifique pour exporter (pas seulement « peut voir »). Si un agent support peut voir un enregistrement mais ne doit pas le télécharger en masse, l'export doit l'empêcher.

Rendez l'isolation tenant impossible à contourner. La requête côté serveur doit toujours appliquer le scope tenant, même si la requête inclut un tenantId, workspaceId ou accountId. Écrivez au moins un test qui tente d'exporter les données d'un autre tenant et prouve que ça retourne zéro ligne.

Confirmez des limites prévisibles. Faites respecter la limite de lignes côté serveur et affichez-la dans l'UI pour éviter les fichiers partiels surprises.

• Le serveur applique un max de lignes (et un temps max) pour chaque export.
• Le tri est stable (mêmes filtres + même fenêtre = même ordre).
• La pagination n'est pas contrôlable par l'utilisateur de manière à contourner la limite.

Planifiez les gros exports. Utilisez un job async quand cela peut prendre plus longtemps qu'une requête normale, et donnez un statut clair : queued, running, finished, failed.

Traitez la livraison comme sensible. Les liens de téléchargement signés doivent expirer rapidement, les fichiers doivent s'auto-supprimer, et les téléchargements ne doivent jamais être devinables. Si vos exports viennent d'un prototype généré par l'IA qui semble « presque prêt » mais manque ces vérifications, FixMyMess peut l'auditer vite et réparer les parties risquées avant la production.

Un exemple réaliste : exports SaaS multi-tenant faits correctement

Imaginez une petite agence qui utilise une application SaaS pour gérer la facturation de plusieurs entreprises clientes (tenants). Un gestionnaire de compte a accès au Client A et au Client B, mais seulement pour les projets auxquels il est assigné.

Il va dans Factures et clique Export pour le Client A. En coulisses, le job d'export est créé avec un scope côté serveur comme tenant_id = Client A, plus les mêmes filtres de rôle et de projet que l'UI utilise.

Le point important : l'utilisateur modifie des paramètres. Il change une valeur de requête de Client A à Client B, ou essaie une autre plage d'ID de facture. Si votre système repose sur le client pour envoyer le bon tenant, vous perdez. Si votre système déduit tenant et permissions depuis la session authentifiée, la requête ne pourra jamais exporter que les données de Client A, même si les paramètres sont trafiqués.

La génération asynchrone garde l'expérience propre. Au lieu d'expirer ou de créer des fichiers à moitié écrits, l'utilisateur voit « L'export est en préparation » et reçoit un fichier fini seulement après la fin du job.

Un setup « bien fait » inclut généralement :

• Le job d'export stocke user_id, tenant_id, et un snapshot des permissions
• La requête est toujours scoppée par tenant et applique les mêmes filtres de permissions
• Cap strict de lignes (ou pages fenêtrées) pour éviter les jobs incontrôlés
• Token de téléchargement à usage unique qui expire rapidement
• Entrée de log d'audit pour démarrage, fin, téléchargement et tentatives refusées

Si un utilisateur signale « j'ai vu la mauvaise facture », ces logs vous permettent de tracer qui a demandé l'export, quel scope a été appliqué, et si des tentatives bloquées ont eu lieu juste avant.

Prochaines étapes : durcir ce que vous avez, puis itérer

Considérez vos endpoints d'export actuels comme une checklist de façons dont ça peut échouer. Cherchez les endroits où un filtre manquant, une requête réutilisée ou un raccourci « admin temporaire » pourrait laisser quelqu'un exporter des données qu'il ne devrait jamais voir.

Rédigez les modes de panne qui vous inquiètent réellement : accès cross-tenant, export de plus de lignes que prévu, export d'enregistrements supprimés ou cachés, et téléchargements qui peuvent être transférés à n'importe qui.

Améliorez ensuite une pièce à la fois, dans cet ordre :

• Scopez chaque requête d'export par tenant et par les permissions réelles de l'utilisateur
• Ajoutez des limites de lignes et une pagination prévisible (et décidez quoi faire quand les utilisateurs atteignent la limite)
• Déplacez les gros exports vers des jobs async avec statut clair et expiration
• Livrez les fichiers avec des téléchargements signés, liés à l'utilisateur et révocables lors de changements de permissions
• Ajoutez des logs d'audit sur qui a exporté quoi et quand

Gardez un petit plan de tests que vous pouvez exécuter avant chaque release. Un bon test : se connecter en tant que Tenant A, lancer un export, puis essayer de modifier la requête (ou de réutiliser le téléchargement) en tant que Tenant B. Si quelque chose fonctionne, vous avez une fuite.

Si vos exports proviennent d'un prototype IA, supposez que les garde-fous sont incomplets. Si vous voulez un second regard rapide, FixMyMess (fixmymess.ai) réalise des audits ciblés et des réparations pour les codebases générées par l'IA, y compris les flux d'export, les lacunes d'isolation tenant et la livraison de fichiers non sécurisée.