Permissions toxiques sur Salesforce : les combinaisons qui créent le risque

Une permission toxique n'est presque jamais un droit dangereux pris isolément. C'est une combinaison de droits qui, séparément, ont tous une bonne raison d'exister. C'est pour ça qu'elle survit aux revues d'habilitation.

Mis à jour le 21 août 2026

Définition

Une permission toxique est un ensemble de droits dont la réunion sur un même compte permet une action qu'aucun de ces droits ne permettait seul. Sur Salesforce, la forme la plus courante associe un droit de lecture étendue, un droit d'écriture ou d'export, et l'absence d'un contrôle qui aurait dû encadrer les deux.

La difficulté n'est pas de reconnaître un droit sensible — tout administrateur sait ce que fait Modifier toutes les données. Elle est de voir qu'il coexiste, sur le même profil, avec une API activée et sans authentification multifacteur. Chaque élément a été accordé à un moment différent, par une personne différente, pour une raison légitime.

Les combinaisons qui reviennent le plus

Lecture totale + export en masse

Afficher toutes les données associé à un droit d'export — API de masse, export hebdomadaire, ou rapport exportable — donne à un compte la capacité d'extraire l'intégralité du référentiel client en une opération. Aucun des deux droits n'est anormal : le premier sert au support, le second au pilotage.

Modification totale + API + MFA absente

C'est la combinaison la plus citée dans les incidents Salesforce. Modifier toutes les données et l'accès API sur un compte qui n'exige pas de second facteur transforme un identifiant compromis en accès complet, sans interaction humaine et sans trace d'interface. Les comptes d'intégration y sont particulièrement exposés : on leur accorde des droits larges parce qu'ils automatisent, et on leur épargne le MFA pour la même raison.

Gestion des utilisateurs + attribution d'ensembles d'autorisations

Un compte qui peut créer des utilisateurs et leur attribuer des ensembles d'autorisations peut s'octroyer indirectement n'importe quel droit. C'est une escalade de privilège au sens strict, et elle ne déclenche aucune alerte native.

Accès invité et communautés

Les profils invités des sites Experience Cloud héritent parfois de droits objet qu'on ne leur destinait pas. Un droit de lecture accordé à un profil invité expose la donnée à un visiteur non authentifié — c'est du contrôle d'accès, pas de la configuration de site.

Applications connectées et jetons OAuth dormants

Une application connectée autorisée il y a deux ans conserve son jeton tant que personne ne le révoque. La question à poser n'est pas « qui a accès ? » mais « quelles portées OAuth ont été accordées, à quoi, et qui s'en sert encore ? ».

Pourquoi une revue manuelle les rate

Une revue d'habilitation regarde les droits profil par profil. Or un utilisateur cumule un profil et un nombre quelconque d'ensembles d'autorisations, chacun apportant sa part. Le droit effectif d'un compte est la somme de ces couches, et cette somme n'est affichée nulle part sous une forme exploitable.

Une org de taille moyenne compte des dizaines de profils, des centaines d'ensembles d'autorisations et des milliers d'utilisateurs. Le produit cartésien à examiner dépasse ce qu'une revue trimestrielle peut couvrir — et il change entre deux revues.

Comment les repérer à l'échelle

1. Calculer le droit effectif par utilisateur, en agrégeant profil et ensembles d'autorisations — pas en lisant les profils un par un.
2. Chercher des combinaisons, pas des droits isolés : c'est la réunion qui fait le risque.
3. Croiser avec l'état d'authentification : le même cumul est bénin derrière un MFA obligatoire et critique sans lui.
4. Inclure les comptes non humains — intégrations, agents, comptes de service. Ils portent souvent les droits les plus larges et les contrôles les plus faibles.
5. Mesurer en continu : une combinaison apparaît le jour où quelqu'un ajoute un ensemble d'autorisations, pas le jour de l'audit.

Combien de temps faut-il pour auditer une org ?

À la main, sur une org de quelques centaines d'utilisateurs, une revue sérieuse des droits effectifs se compte en jours — et elle est périmée le lendemain. Instrumentée, la même mesure se rejoue à chaque scan, ce qui déplace l'effort de la collecte vers la décision.

Que faire d'une permission toxique une fois trouvée ?

Rarement la supprimer d'emblée : elle sert à quelque chose. L'ordre utile est de déterminer qui l'utilise réellement, de couvrir le risque par un contrôle compensatoire — MFA obligatoire, restriction d'adresse IP, réduction de portée OAuth — puis de retirer ce qui n'est plus employé. C'est pour ça qu'un outil de détection doit rester en lecture seule : la décision de retirer un droit en production appartient à l'humain qui en connaît l'usage.