tenantleakCloud

Un client ne doit jamais voir les données d'un autre.

tenantleak Cloud rejoue les requêtes de votre API avec les comptes de deux clients différents. Quand l'un atteint les données de l'autre, vous recevez la requête exacte qui le prouve, avant qu'un client ne la trouve à votre place.

Essayer gratuitement Ouvrir la démo

Gratuit pour une API, sans carte bancaire. REST et GraphQL. Lecture seule par défaut. La démo montre une organisation réelle, scannée sur une API volontairement vulnérable, sans inscription.

Scan n°13lundi, 6 h 00

Acme client A

Globex client B

Facture n°8812 12 480,00 € appartient à Acme
bob@globex.io GET/api/invoices/8812 
HTTP/1.1 200 OK
{
  "id": 8812,
  "client": "Acme SAS",
  "montant": 12480.00,
  "iban": "FR76 3000 4000 0312 3456 7890 143"
}
Critique

Lecture des données d'un autre client : avec le jeton de Globex, l'API renvoie une facture d'Acme. OWASP API1:2023

Scan n°14mardi, 6 h 00

GET/api/invoices/8812 403 Forbidden Corrigé

Exemple : un utilisateur du client Globex demande la facture 8812, qui appartient au client Acme. L'API la renvoie : c'est une fuite entre clients, classée critique. Au scan suivant, après correction, la même requête est refusée avec une erreur 403.

Ce que chaque scan vérifie

Le risque n°1 du Top 10 OWASP des API, et ses variantes. Sur une spec OpenAPI (URL ou fichier), une capture HAR ou un endpoint GraphQL.

Lecture croisée d'objets

GET /invoices/8812

Le compte du client B demande chaque objet du client A, identifiant par identifiant.

Écriture croisée

PATCH /projects/41

Sur votre préproduction et avec l'offre Business : modifier un objet d'un autre client doit être refusé. Jamais de suppression.

Sélecteur de tenant manipulé

X-Tenant-Id: acme

Changer l'en-tête ou le paramètre qui désigne le client ne doit pas suffire à en changer.

Accès anonyme

sans jeton

Chaque endpoint qui renvoie des données client doit exiger une authentification.

Secrets dans les réponses

"password_hash": "$2b$12…"

Empreintes de mots de passe, clés d'API et jetons ne doivent jamais quitter le serveur.

GraphQL

query { node(id: "…") }

Les mêmes contrôles sur les requêtes et les nœuds GraphQL, à partir de l'introspection ou de votre schéma.

Quatre étapes, une seule fois

Ensuite, les scans tournent seuls, à l'heure que vous choisissez ou à chaque déploiement.

  1. Prouver que le domaine est à vous

    Un enregistrement DNS ou un petit fichier. Nous ne scannons jamais un domaine dont le contrôle n'a pas été prouvé.

    _tenantleak.api.exemple.fr TXT

  2. Décrire l'API

    L'URL de sa spec OpenAPI, le fichier lui-même, une capture HAR prise dans le navigateur, ou l'endpoint GraphQL.

    https://api.exemple.fr/openapi.json

  3. Ajouter deux comptes de test de deux clients

    Un utilisateur d'Acme, un utilisateur de Globex, sur votre préproduction. Jeton, cookie ou identifiant et mot de passe.

    alice@acme / bob@globex

  4. Laisser tourner

    Scan quotidien ou hebdomadaire, alerte e-mail, Slack, Teams ou Discord, webhook signé pour vos outils, et une action GitHub pour bloquer un déploiement.

    uses: Chechene953/tenantleak/cloud-action@v0

Un problème n'est corrigé que lorsqu'on l'a vérifié

Chaque faille devient un problème suivi d'un scan à l'autre. Il passe à « Corrigé » uniquement quand le même test a été rejoué et refusé, pas parce qu'il a disparu d'un rapport.

Correctif déployé ? Un clic rejoue uniquement cet endpoint, en une minute, hors quota. Vous pouvez aussi accepter un risque jusqu'à une date, ou marquer un faux positif : la raison reste dans le journal, visible de toute l'équipe.

Chaque scan dit aussi ce qu'il n'a pas pu tester et pourquoi, et produit un rapport en français à transmettre à vos clients ou à un auditeur.

GravitéProblèmeÉtat
Critique Lecture des données d'un autre client
GET /api/invoices/{id} Nouveau		 Ouvert
Élevée Bascule de tenant par en-tête ou paramètre
GET /api/projects		 Ouvert
Critique Modification des données d'un autre client
PATCH /api/projects/{id}		 Corrigé
Moyenne Données sensibles dans les réponses
GET /api/users/me		 Risque accepté
jusqu'au 31/12

Conçu pour ne rien casser

Lecture seule par défaut
Seules des requêtes de lecture sont envoyées. Les tests d'écriture sont réservés à la préproduction, sur attestation, avec l'offre Business.
5 requêtes par seconde
Un débit plafonné, quatre requêtes en parallèle au plus, et 15 minutes au maximum par scan.
5 000 requêtes par scan
Un budget fixe : le scan s'arrête de lui-même s'il est atteint, avec des résultats partiels clairement signalés.
Domaines vérifiés uniquement
Aucune requête vers un hôte dont vous n'avez pas prouvé le contrôle, ni vers une adresse privée.

Comment nous protégeons vos API et vos identifiants

Offres

Prix HT par mois, sans engagement. TVA non applicable, article 293 B du CGI.

Comparer les offres

  • Découverte

    0 € HT / mois

    Pour vérifier une API une fois, gratuitement.

    1 API REST, 3 scans par mois, Rapport détaillé avec preuves.

    Commencer gratuitement

  • Pro

    49 € HT / mois

    Pour surveiller l'isolation entre clients à chaque déploiement.

    3 API, REST et GraphQL, Scans quotidiens planifiés, Alertes e-mail, Slack, Teams et Discord, API, action GitHub et webhooks signés, 5 membres.

    Choisir Pro

  • Business

    199 € HT / mois

    Pour les équipes qui testent aussi les écritures sur leur préproduction.

    15 API, Tests d'écriture sur préproduction, Membres illimités (50), Connexion SSO (OpenID Connect), Revue trimestrielle d'une heure avec un pentester RedSentinel, Support prioritaire.

    Choisir Business

Derrière l'outil, un pentester

tenantleak Cloud est édité par RedSentinel, cabinet de tests d'intrusion. Le moteur de scan est celui que nous utilisons en mission pour trouver les fuites entre clients dans les applications SaaS ; il est publié en open source.

Un scan automatique couvre la classe de failles la plus répandue des API multi-clients. Il ne remplace pas un pentest : la logique métier, les parcours de paiement ou l'élévation de privilèges entre rôles demandent un regard humain.

Réserver un échange de 30 minutes

Questions fréquentes

Le scan peut-il perturber ma production ?

Par défaut il n'envoie que des lectures, à 5 requêtes par seconde au plus, avec un budget fixe. Nous recommandons malgré tout de viser une préproduction alimentée avec deux clients de test.

Pourquoi faut-il deux comptes de deux clients différents ?

Pour savoir si le client B peut lire les données du client A, il faut des objets qui appartiennent à A et un jeton qui appartient à B. Le scan collecte les identifiants de chaque compte, puis les échange.

Que deviennent mes identifiants de test ?

Ils sont chiffrés dès l'enregistrement, avec une clé conservée à part de la base, et ne sont plus jamais affichés. Ils ne servent qu'à appeler les domaines que vous avez vérifiés.

Mon API n'a pas de spécification OpenAPI.

Naviguez dans votre application avec les outils de développement ouverts, exportez une capture HAR et envoyez-la : les endpoints sont reconstruits à partir des requêtes réelles.

Est-ce que cela s'intègre à ma CI ?

Oui, avec les offres Pro et Business : un jeton d'API lance un scan, attend son verdict et fait échouer le job en cas de nouvelle faille. Le rapport SARIF s'affiche dans GitHub. Voir la documentation.

Est-ce que cela remplace un test d'intrusion ?

Non. Il vérifie en continu le cloisonnement entre clients, ce qu'un pentest ponctuel ne fait qu'une fois. Pour le reste, parlons-en.

Savoir avant vos clients.

Une API, trois scans par mois, gratuitement. Comptez une dizaine de minutes pour la configurer.

Créer un compte Lire la documentation