Le portail semble fonctionner. Chaque compte affiche ses projets, la démonstration se déroule bien et le bouton d’export produit un fichier. Avant d’accepter la fonctionnalité, une question mérite pourtant une réponse précise : le cloisonnement entre clients tient-il aussi lorsque les données quittent l’écran ?
Pour le directeur technique d’un SaaS B2B, l’isolation consiste à limiter chaque client aux ressources et aux actions que son organisation et son rôle lui permettent. Cet espace peut s’appeler organisation, compte, workspace ou tenant. L’enjeu reste la règle d’accès que l’application doit faire respecter.
Des avis de sécurité publics montrent pourquoi il faut suivre plusieurs chemins. Une requête classique, un export et un abonnement aux notifications peuvent présenter des défauts distincts. Le bon fonctionnement de l’un ne renseigne pas sur les autres.
L’essentiel en 60 secondes
Choisissez un parcours client et écrivez les accès qu’il doit autoriser et refuser. Suivez les données depuis la requête jusqu’au traitement en arrière-plan, au fichier produit et aux notifications. Demandez des preuves obtenues sur un environnement de test autorisé, avec des clients fictifs, en associant à chaque refus attendu un cas autorisé qui fonctionne.
Limitez ensuite la conclusion à ce qui a été examiné : rôle, ressource, action, chemin d’accès et version. Un export ou un canal de notifications non testé reste une question ouverte, même si l’écran principal se comporte correctement.
1. Écrire la règle d’accès avant de la vérifier
« L’utilisateur est connecté » établit son identité. Cela ne dit pas s’il peut lire ce document, exporter ce rapport ou recevoir les événements de cette organisation.
Lors d’un appel avec un directeur technique, nous l’avons formulé ainsi : « La connexion indique au serveur qui fait la demande. Elle ne lui dit pas à quoi cette personne a droit. Chaque requête, chaque fichier et chaque notification doit encore répondre à une question : l’organisation de cette personne possède-t-elle cet enregistrement ? »
Le risque API1:2023 décrit par OWASP concerne l’autorisation au niveau de l’objet : vérifier les droits sur l’action et la ressource demandées. OWASP cite les UUID, comme les entiers séquentiels, parmi les identifiants qu’un attaquant peut manipuler : un identifiant difficile à deviner ne donne donc pas ces droits.
Un conseil que nous contestons : « les identifiants sont des UUID, donc personne ne peut atteindre ces enregistrements ». Un identifiant difficile à deviner circule pourtant dans les exports, les journaux, les liens partagés et les notifications ; il ne peut donc pas remplacer le contrôle des droits. Le contrôle que nous jugeons obligatoire est une paire sur chaque mode de livraison : une requête autorisée, et une requête refusée provenant d’une seconde organisation.
Formulez la règle en termes de produit. Par exemple : un membre de l’organisation A peut lire ses tickets ; un administrateur de A peut les exporter ; aucun des deux ne peut obtenir ceux de B. Si un opérateur de support intervient légitimement chez plusieurs clients, décrivez séparément cette habilitation et ses limites.
L’équipe dispose alors d’une référence commune pour la recette. Une requête refusée n’est rassurante que si elle devait l’être. Une requête acceptée n’est correcte que si elle retourne les données autorisées.
2. Deux avis de sécurité, trois frontières différentes
Les mécanismes suivants sont décrits par les éditeurs. Cette synthèse ne repose sur aucune reproduction par IZZY.
L’avis Daytona de juin 2026 décrit un canal de notifications qui acceptait le choix d’une organisation sans vérifier l’appartenance sur le parcours JWT. Un utilisateur authentifié pouvait recevoir les événements d’une autre organisation. L’avis précise que l’authentification par clé API n’était pas concernée.
L’avis ToolJet d’août 2026 distingue deux défauts d’export : divulgation des schémas de tables TooljetDB entre espaces de travail, et export de la définition d’une autre application dans le même espace malgré les droits granulaires. Les schémas ne sont pas les lignes des tables ; le second défaut n’est pas présenté comme un export d’application entre espaces.
| Mécanisme décrit | Question à reprendre pour votre produit |
|---|---|
| Daytona : appartenance à l’organisation lors de l’abonnement | Qu’est-ce qui autorise la réception des notifications de cette organisation ? |
| ToolJet : frontière entre espaces pour l’export de schémas | À quel client appartient le contenu sélectionné pour l’export ? |
| ToolJet : droits sur une application du même espace | L’accès à une application permet-il d’en exporter une autre ? |
Cette comparaison change la preuve à demander. « Nous avons vérifié la connexion » laisse ouverte la question de l’abonnement. « Nous avons vérifié l’espace de travail » peut laisser ouverte celle des droits sur chaque ressource.
Ces avis n’établissent ni une vulnérabilité de votre produit, ni une exploitation observée, ni l’état actuel des déploiements des éditeurs. Leurs métadonnées de gravité divergent ; aucun score n’est nécessaire à cette analyse.
3. Suivre une donnée client jusqu’au bout du parcours
Prenons un portail de support fictif. L’organisation A possède un ticket de test marqué A-DEMO et l’organisation B un ticket marqué B-DEMO. Ces données sont inventées pour l’exemple ; elles ne reconstituent aucun des deux avis.
Un administrateur de A consulte ses tickets, demande un rapport, attend sa génération, télécharge le fichier et reçoit une notification. Le parcours comporte plusieurs décisions :
- La requête sélectionne les tickets que cet administrateur peut lire.
- Le traitement en arrière-plan conserve l’organisation et le périmètre de l’export.
- Le fichier produit contient les enregistrements prévus.
- Le téléchargement respecte les règles d’accès ou de partage convenues.
- La notification transmet le contenu autorisé aux bons destinataires.
Pour chaque passage, identifiez le composant qui applique la règle. Un filtre d’affichage n’explique pas la sélection opérée par l’exporteur. L’autorisation de lancer un traitement n’explique pas qui peut en récupérer le résultat.
Précisez aussi le partage prévu. Un lien temporaire donnant accès à son détenteur peut être un choix fonctionnel assumé. Il faut alors définir et vérifier sa durée de validité et les attentes de révocation. L’évaluer comme s’il exigeait une nouvelle connexion conduirait à tester une autre règle que celle du produit.
4. Demander ensemble les preuves d’accès et de refus
Voici un exemple de recette pour ce portail fictif. Il faut adapter les résultats attendus à la politique réelle avant le test. Le tableau ne contient aucun résultat observé.
| Chemin | Cas autorisé attendu | Cas refusé attendu | Trace à conserver |
|---|---|---|---|
| Lecture d’un ticket | Un membre de A lit A-DEMO |
Il ne peut pas lire B-DEMO |
Rôle, donnée de test, réponse et version |
| Génération et récupération du rapport | L’administrateur habilité obtient les données prévues de A | L’opération ne peut pas inclure celles de B | Contexte du traitement et contenu du fichier fictif |
| Rôle limité | Un lecteur consulte les tickets permis | Il ne peut pas exporter si la politique ne lui accorde pas ce droit | Les deux résultats sous la même politique de droits |
| Notifications en temps réel | L’événement destiné à A arrive | L’événement de B n’est pas transmis à A | Événements de test, décision d’abonnement et fenêtre d’observation |
Un client temps réel silencieux ne suffit pas à démontrer un refus : aucun événement n’a peut-être été émis, ou la connexion a échoué. Vérifiez que l’événement autorisé a été produit puis reçu. Examinez ensuite la trace du refus d’abonnement ou de l’absence de livraison sur une durée définie. Si la preuve manque, gardez ce résultat comme incertain.
Utilisez uniquement des environnements et des comptes dont le test est autorisé. Les données synthétiques permettent de montrer la frontière sans récupérer les informations d’un autre client réel. Arrêtez la démonstration à la preuve convenue ; une extraction massive n’apporte rien à cette recette.
5. Corriger le chemin qui laisse passer les données
Le guide multitenant d’OWASP relie le contexte client, les accès aux données, les caches, les traitements asynchrones et le stockage. L’isolation de la base constitue une couche de protection ; elle ne remplace pas l’examen des chemins réellement utilisés par l’application.
Lorsqu’un cas échoue, cherchez la décision incorrecte. Une organisation a-t-elle été acceptée sans vérification d’appartenance ? Le traitement a-t-il perdu son périmètre ? Un droit propre à une ressource a-t-il disparu lors de l’ajout d’un export ? La réponse détermine le correctif et les cas voisins à revérifier.
Conservez le cas autorisé dans cette vérification. Bloquer tous les exports peut supprimer la divulgation observée tout en rendant la fonctionnalité inutilisable. Utilisez aussi l’identité et la configuration normales de l’application : un parcours réservé au test ne prouve pas le comportement du parcours exploité.
Pour les données personnelles, les recommandations de la CNIL sur les API invitent aussi à identifier les acteurs et leur rôle afin d’organiser le périmètre d’accès de chacun aux API et aux données, et à limiter le partage aux données strictement nécessaires, aux personnes et aux finalités prévues. Elles soutiennent cet examen du parcours complet, sans attester la conformité d’une application particulière.
6. Accepter ce qui est démontré et nommer ce qui reste ouvert
Avant l’arbitrage de mise en production, rassemblez la règle attendue, la version et l’environnement examinés, les résultats autorisés et refusés, le responsable du correctif et les chemins non testés. « Requêtes vérifiées ; téléchargement de l’export non examiné » donne à quelqu’un une question précise à traiter.
Là où nous fixons la limite : après une revue limitée, nous nommons les chemins, les rôles et la version que nous avons vérifiés. Nous ne qualifions pas le produit d’isolé sur la foi de chemins que nous n’avons pas testés.
Si une autre équipe doit exploiter le produit, joignez ce dossier aux preuves de reprise de la base de code. Si un constat exige une correction livrée, attribuez sa responsabilité jusqu’à la mise en production et à sa vérification, comme dans le parcours de traitement d’un signalement de sécurité.
Commencez par la prochaine fonctionnalité qui manipule des données client. Demandez à son responsable d’expliquer un parcours permis et un parcours interdit à travers chaque mode de livraison. La première réponse manquante désigne le prochain point à examiner.
Vérifions cette frontière ensemble
Si cette frontière devient difficile à suivre dans une base de code héritée, apportez le parcours, l’architecture et les tests existants à un échange sur le sauvetage et le durcissement de code d’IZZY. Il s’agit de préparation ou de correction côté ingénierie. Faites intervenir séparément un prestataire de test d’intrusion lorsque vous avez besoin de cette vérification indépendante.
Sources et limites
Synthèse documentaire vérifiée le 10 novembre 2026. Les avis Daytona et ToolJet décrivent des mécanismes historiques distincts ; aucun exploit n’a été reproduit et aucun état actuel des déploiements n’est affirmé. OWASP et la CNIL apportent des recommandations, sans valider le portail fictif. Le parcours, ses données et ses résultats attendus sont des exemples à adapter, pas un cas client IZZY ni une évaluation complète de sécurité.