Un client peut-il lire les données d'un autre dans votre SaaS ?

Deux entreprises utilisent la même application. Chacune voit son nom dans l'en-tête, ses commandes et ses rapports. Cela ressemble à une séparation, mais l'interface affiche seulement ce qu'elle reçoit. La protection doit intervenir avant que le serveur renvoie les données.

Prenons une route qui cherche une commande par son identifiant. Si le serveur vérifie uniquement la présence d'une session, une personne connectée peut recevoir la commande d'une autre entreprise. L'interface n'a même pas besoin de proposer un bouton pour l'ouvrir.

C'est un test utile avant d'ajouter des rapports ou une recherche par IA. Chaque nouvel accès aux données doit respecter la séparation entre clients.

Déterminez l'organisation côté serveur

Le navigateur peut indiquer l'organisation sélectionnée. Le serveur doit vérifier la session, confirmer l'appartenance à cette organisation et autoriser l'action demandée. Un identifiant envoyé dans un formulaire ne prouve aucun droit d'accès.

Le guide d'autorisation de l'OWASP recommande de refuser par défaut et de vérifier les permissions à chaque requête. Masquer des contrôles dans l'interface ne remplace pas cette vérification.

Après avoir autorisé la lecture, une requête paramétrée peut limiter la commande à l'organisation vérifiée :

SELECT id, status, created_at
FROM orders
WHERE organization_id = $1
  AND id = $2;

Ici, $1 vient du contexte validé par le serveur. $2 correspond à la commande demandée. La requête illustre le filtre d'organisation, mais pas toute la politique d'accès. Un membre de l'entreprise peut avoir le droit de lire uniquement ses propres commandes.

Appliquez le même raisonnement aux modifications et aux suppressions. Vérifiez les relations. Une commande de l'entreprise A ne doit pas accepter une référence vers un client de l'entreprise B simplement parce que les deux enregistrements existent.

La base peut renforcer la règle

PostgreSQL propose des politiques par ligne. Les superutilisateurs et les rôles BYPASSRLS les contournent. Le propriétaire de la table aussi, généralement, sauf avec FORCE ROW LEVEL SECURITY.

Si vous adoptez cette fonction, testez avec le rôle utilisé par l'application en production. Un test exécuté comme administrateur peut donner une fausse impression de protection. Vérifiez quel contexte d'organisation atteint la base et comment il se termine après chaque opération.

Pour les connexions réutilisées, nous recommandons de transmettre ce contexte dans une transaction et de limiter sa durée à celle-ci. Le traitement suivant ne doit pas hériter de l'organisation précédente. L'absence de contexte doit empêcher l'accès et faire l'objet d'un test.

Cherchez les sorties hors de la liste

Une application peut protéger sa requête de commandes et divulguer des données par un rapport exporté. Inventoriez les chemins qui livrent de l'information aux utilisateurs.

La clé du cache doit distinguer l'organisation et le périmètre d'accès pertinent. Une réponse trouvée en cache doit respecter l'autorisation actuelle. Pour les fichiers, vérifiez l'accès avant de délivrer un lien temporaire de téléchargement.

Pour un traitement en arrière-plan, enregistrez l'organisation et l'identité responsable. Décidez s'il utilise les permissions actuelles du demandeur ou une permission de service explicite. Retirer une personne de l'entreprise ne doit pas laisser cette décision au hasard.

Incluez la recherche par IA dans la revue. Filtrez les documents autorisés avant de les envoyer au modèle. Lui demander de ne pas révéler les données des autres clients ne corrige pas une requête qui les a déjà récupérées.

Testez toujours avec deux entreprises

Créez des données fictives pour deux organisations. Exécutez la même opération avec un utilisateur de chacune et essayez de croiser les identifiants. Couvrez les lectures, les écritures et les téléchargements.

Répétez une requête après que l'autre organisation a rempli le cache. Testez une tâche créée avant le retrait d'un utilisateur. Essayez aussi une demande sans contexte d'organisation. Un test de connexion ne couvre pas ces cas.

Le résultat attendu inclut l'effet sur le stockage. Refuser la réponse après avoir enregistré une modification interdite ne suffit pas.

Avant de publier la prochaine fonction, listez les données qu'elle lit et les chemins par lesquels elles sortent. Parcourez cette liste avec le compte de l'autre entreprise. Ce test en dit plus que le bon nom dans l'en-tête.