Sécurité des Connected Apps Salesforce : guide de préparation

Salesforce fait passer l'accès des Connected Apps de « ouvert par défaut » à « approuvé par défaut ». Les Connected Apps non installées sont désormais bloquées pour la plupart des utilisateurs, OAuth 2.0 Device Flow est en cours de retrait et Salesforce oriente tout le monde vers les External Client Apps comme solution de remplacement à long terme. Si votre org n'a pas audité ce qui est réellement autorisé à s'y connecter, une intégration cassera avant que vous ne compreniez pourquoi.

Qu'est-ce qui change réellement pour les Connected Apps ?

Salesforce bloque désormais par défaut les Connected Apps non installées : toute application autorisée par un utilisateur de son propre chef, sans installation formelle par un admin dans l'org, perd son accès sauf si quelqu'un accorde une permission de contournement spécifique. Les applications qui reposent encore sur OAuth 2.0 Device Flow perdent purement et simplement leur accès, même si elles étaient autorisées auparavant. À plus long terme, Salesforce abandonne la Connected App classique comme objet d'intégration principal au profit des External Client Apps, qui séparent la définition de l'application de ses politiques et donnent aux admins un contrôle plus fin sur les scopes, les plages IP et le comportement des sessions.

Pourquoi Salesforce durcit-il les règles maintenant ?

En bref : l'autorisation OAuth est devenue une cible de choix. Des attaquants se faisant passer pour le support informatique ont convaincu des employés d'approuver des connected apps d'apparence légitime, puis ont utilisé cet accès pour extraire discrètement des données pendant des semaines. C'est un problème d'ingénierie sociale, pas une vulnérabilité de la plateforme, mais la réponse de Salesforce est architecturale : la posture par défaut devient « rien ne se connecte tant qu'un admin ne l'a pas décidé ».

Ce changement est raisonnable. Il signifie aussi que l'hygiène de l'org, autrefois facultative, savoir exactement quelles applications ont un accès API et pourquoi, fait désormais la différence entre un mardi tranquille et une réunion de crise imprévue.

Où les intégrations cassent-elles concrètement ?

D'après notre expérience d'accompagnement d'orgs Salesforce lors des évolutions de la plateforme, les pannes surviennent rarement là où les équipes les attendent. Surveillez :

• Les connecteurs middleware et iPaaS configurés il y a des années par quelqu'un qui a quitté l'équipe, sans responsable documenté.
• Les jobs Data Loader et les scripts ETL planifiés qui utilisent encore OAuth Device Flow pour leurs exécutions sans surveillance.
• Les outils de reporting ou de BI autorisés par un utilisateur individuel plutôt qu'installés à l'échelle de l'org.
• Les applications de partenaires ou d'ISV jamais installées formellement, simplement autorisées une fois pendant un pilote.

Chacun de ces cas peut passer inaperçu pendant des mois jusqu'à ce que la restriction s'applique et que le job de synchronisation s'arrête, souvent sans erreur claire qui renvoie à la cause.

Comment auditer votre org avant que les restrictions ne s'appliquent ?

Inutile d'ajouter de nouveaux outils, il suffit d'un passage méthodique dans Setup :

• Ouvrez Setup > Connected Apps OAuth Usage et listez chaque application actuellement autorisée, pas seulement celles que vous avez installées.
• Repérez tout ce qui affiche une action « Install » : c'est votre liste d'applications non installées et à risque.
• Vérifiez les dates de dernière utilisation. Les applications sans activité récente sont à révoquer, pas à conserver « au cas où ».
• Confirmez la politique API Access Control de votre org et qui détient la permission « Approve Uninstalled Connected Apps ».
• Pour tout ce que vous conservez, notez qui en est responsable et pourquoi. Ce registre vous fera gagner du temps lors du prochain changement de plateforme, pas seulement pour celui-ci.

Que faut-il changer dans la gouvernance des intégrations à l'avenir ?

Voyez cela comme une occasion de formaliser la gouvernance des intégrations, pas comme un nettoyage ponctuel. Les nouvelles intégrations doivent être installées et délimitées délibérément dès le premier jour, et non autorisées au coup par coup par la personne qui les a mises en place. Si vous prévoyez de nouvelles connexions externes, les construire d'emblée comme External Client Apps vous évite une seconde migration plus tard.

C'est exactement le type de travail que nous menons aux côtés des équipes Salesforce internes : cartographier les intégrations existantes, décider ce qu'il faut garder, retirer ou reconstruire, puis intégrer le résultat dans un processus de développement qui traite le contrôle d'accès comme une partie de la release, pas comme un détail de dernière minute.

Si vous préférez que quelqu'un passe en revue avec vous l'inventaire des Connected Apps de votre org avant la prochaine mise à jour de la plateforme, contactez-nous et nous vous aiderons à transformer cette checklist en un processus reproductible.

FAQ

Cela va-t-il casser mes intégrations Salesforce existantes ?

Seulement si elles ne sont pas installées ou si elles utilisent encore OAuth 2.0 Device Flow. Les applications installées et les flux d'authentification modernes continuent de fonctionner sans changement.

Quelle est la différence entre une Connected App et une External Client App ?

Les External Client Apps séparent l'identité de l'application de ses politiques d'accès, ce qui donne aux admins un contrôle plus précis sur les scopes et les sessions. Salesforce les présente comme le remplacement à long terme des Connected Apps classiques.

Qui doit recevoir la permission « Approve Uninstalled Connected Apps » ?

Gardez ce groupe restreint, aux admins qui testent de nouvelles applications et aux développeurs qui maintiennent les intégrations, car il s'agit d'un contournement global et non d'une autorisation par application.

À quelle fréquence faut-il revoir l'accès des Connected Apps ?

Au minimum chaque trimestre, et immédiatement après chaque release de sécurité Salesforce, car l'élargissement des autorisations se fait progressivement et passe facilement inaperçu.