Allez dans Setup → Connected Apps OAuth Usage de votre Salesforce. Vous y verrez probablement une liste à laquelle vous ne vous attendiez pas : 30, 50, parfois plus de 100 applications connectées via OAuth. Certaines portent un nom familier (Outlook, Slack, Marketing Cloud). D’autres beaucoup moins (« DataLoader », « Salesforce CLI by John Doe », « Internal Workflow App »).
Bienvenue dans la jungle des Connected Apps. C’est l’une des zones les moins gouvernées des instances Salesforce, et c’est exactement par là que les attaques UNC6040 / ShinyHunters sont entrées chez Google, LVMH, Adidas et des centaines d’autres en 2025.
Qu’est-ce qu’une Connected App
Une Connected App est une application externe qui se connecte à votre instance Salesforce via OAuth. Le mécanisme est simple :
- Un utilisateur autorise une application externe à accéder à Salesforce en son nom.
- Salesforce émet un token OAuth qui permet à l’application d’agir.
- Le token reste valide tant qu’il n’est pas révoqué (parfois plusieurs mois ou années sans MFA).
C’est puissant, c’est utile, et c’est dangereux quand ce n’est pas gouverné.
Pourquoi c’est un risque sécurité majeur
Une Connected App malveillante (ou compromise) peut faire des dégâts considérables :
- Exfiltrer massivement des données via API, dans la limite des permissions de l’utilisateur qui a autorisé.
- Contourner la MFA, parce que le token OAuth ne demande pas de second facteur à chaque appel.
- Persister des mois ou des années sans détection si Event Monitoring n’est pas activé.
- Évader les restrictions IP si elles ne sont pas configurées au niveau de la Connected App.
Voir le rapport Google Threat Intelligence sur UNC6040 : la quasi-totalité des attaques 2025 sur Salesforce ont utilisé une fausse Connected App Data Loader installée par vishing.
L’audit Connected Apps : 7 questions à se poser
- 1. Combien d’apps sont connectées à votre org ? Allez dans Setup → Connected Apps OAuth Usage. Comptez. Au-delà de 30, c’est qu’il y a probablement du nettoyage à faire.
- 2. Quelles apps n’ont pas été utilisées depuis 90 jours ? Salesforce indique le « Last Used Date ». Tout ce qui n’a pas servi depuis 6 mois mérite une revue, généralement une révocation.
- 3. Quelles apps ont des permissions « Full Access » ? C’est rare que ce soit nécessaire. La plupart des apps n’ont besoin que d’API access ou de Refresh Token. Full Access = privilege escalation potentielle.
- 4. Qui a autorisé chaque app ? Salesforce trace l’utilisateur qui a fait l’autorisation. Si une app a été autorisée par 50 utilisateurs, c’est une app interne légitime. Si elle a été autorisée par 1 seul utilisateur (l’admin Salesforce), c’est probablement à investiguer.
- 5. L’app vient-elle d’un éditeur connu ? Microsoft, Slack, Salesforce, Tableau, MuleSoft, Gearset, OwnBackup, JustOn — connus. Une app au nom générique sans éditeur clair = drapeau rouge.
- 6. L’app respecte-t-elle les restrictions IP de votre org ? Les Connected Apps peuvent être configurées pour respecter ou contourner les restrictions IP. Vérifiez le paramètre IP Relaxation.
- 7. Une revue d’app a-t-elle été faite récemment ? Date de dernière revue documentée. Si jamais, c’est par là qu’il faut commencer.
Comment auditer en pratique
- Étape 1 — Inventaire : exporter la liste des Connected Apps depuis Setup. Utiliser le rapport « OAuth Usage Report » sur 90 jours pour avoir le volume d’utilisation.
- Étape 2 — Classement : chaque app reçoit un statut — légitime, à investiguer, à révoquer.
- Étape 3 — Investigation : pour chaque app à investiguer, identifier l’éditeur, le cas d’usage métier, le sponsor interne. Documenter.
- Étape 4 — Révocation : pour les apps non justifiées, révoquer immédiatement (Setup → Connected Apps → Manage → Revoke). L’utilisateur affecté devra réautoriser légitimement si besoin.
- Étape 5 — Gouvernance : mettre en place une procédure d’autorisation préalable de toute nouvelle Connected App. Salesforce permet de bloquer les nouvelles autorisations OAuth via le paramètre « OAuth Apps White List » au niveau Profile ou Permission Set.
Mettre en place la gouvernance permanente
- Whitelisting : configurer la « OAuth Apps White List » avec uniquement les apps approuvées. Toute nouvelle tentative d’autorisation est bloquée.
- Process d’approbation : toute demande d’ajout d’une nouvelle app passe par un workflow d’approbation (RSSI, DSI ou admin senior).
- Surveillance Event Monitoring : configurer une alerte sur les événements OAuth Apps pour détecter les nouvelles autorisations.
- Revue trimestrielle : audit récurrent de la liste des Connected Apps avec ré-validation explicite.
- Documentation : tableau partagé qui liste, pour chaque app : éditeur, cas d’usage, sponsor, date d’approbation, date de prochaine revue.
Conclusion : les Connected Apps, le shadow IT version Salesforce
Les Connected Apps sont l’équivalent du shadow IT pour Salesforce. Sans gouvernance, c’est par là qu’arrivent les fuites massives. Avec une gouvernance simple — inventaire, whitelisting, revue trimestrielle —, c’est un risque maîtrisé.
Si vous n’avez jamais audité vos Connected Apps, c’est probablement le quick win sécurité le plus rentable que vous puissiez faire ce trimestre. Comptez 1 à 2 jours d’audit, plus 1 à 2 jours de mise en place de la gouvernance.
Voir aussi notre article sur Event Monitoring pour la couche surveillance, et notre livre blanc Sécurité Salesforce pour la méthodologie complète. Pour un audit complet de votre instance, contactez-nous sur cloudgirafe.fr.
