Des mauvaises configurations découvertes dans Industry Cloud de Salesforce

Les problèmes de configuration peuvent avoir des conséquences fâcheuses pour la cybersécurité. Des chercheurs d’AppOmni ont découvert une vingtaine de paramétrages et comportements non sécurisés dans Industry Cloud de Salesforce. Plus exactement les soucis se trouvent dans le composant de développement d’applications low-code de la plateforme. Les attaquants peuvent ainsi accéder aux informations clients chiffrées, aux données de session, aux identifiants et à la logique métier, selon des chercheurs en sécurité.

La suite Industry Cloud comprend une solution low-code nommée OmniStudio intégrant des outils de transformation numérique préintégrés pour des secteurs spécifiques, tels que les services financiers et l’industrie. Destinés aux développeurs métiers, elle propose  aux « utilisateurs non techniques de créer une logique qui touche aux systèmes critiques et aux données clients et internes sensibles, explique Aaron Costello, responsable de la recherche en sécurité SaaS chez AppOmni, dans un rapport. Cependant, cette autonomisation peut avoir un coût en matière de sécurité, augmentant considérablement le risque de mauvaises configurations de la part des clients ». Mais il ajoute : « cette combinaison de flexibilité et de confiance implicite signifie qu’un client qui configure mal un composant ou néglige un paramètre peut entraîner une exposition des données à l’échelle du système.»

Plusieurs risques identifiés

AppOmni a recensé plusieurs risques dont la non-application par les composants low-code des contrôles d’accès ou du non-respect des champs de données chiffrés par défaut. De même, les mauvaises configurations peuvent offrir du code de workflow exécutable par des utilisateurs externes ou non authentifiés. Les mécanismes de mise en cache pouvant conduire à des contournements des contrôles d’accès.

Il peut arriver également que des applications hors plateforme mal développées entraînent le vol de jetons d’API. Pire, des clés d’API sensibles et d’autres données intégrées directement dans les composants peuvent être lues sans autorisation. Enfin, il peut arriver que des authentifications non sécurisées soient présentes sur les workflows enregistrés.

Face à ces différentes menaces, Salesforce est intervenu en publiant 5 CVE qui corrigent des bugs dans les composants FlexCards et Data Mappers d’OmniStudio. Salesforce a informé ses clients de ces problèmes le 19 mai. Les FlexCards, qui récupèrent des données de Salesforce et de sources tierces pour les utiliser dans des workflows ou les afficher dans des vues web destinées aux clients, sont à l’origine de quatre de ces CVE :

CVE-2025-43698 : La source de données SOQL ignore la sécurité au niveau des champs (FLS), exposant ainsi toutes les données des champs des enregistrements.

CVE-2025-43699 : Le champ « Autorisations requises » peut être contourné, car la vérification est effectuée côté client.

CVE-2025-43700 : L’autorisation « Afficher les données chiffrées » n’est pas appliquée, ce qui renvoie des valeurs en texte clair pour les données utilisant le chiffrement classique à des utilisateurs non autorisés. CVE-2025-43701 : Permet aux utilisateurs invités d’accéder aux valeurs des paramètres personnalisés.

Les Data mapper sont une fonctionnalité disponible en option pour les sources de données FlexCards ou en tant qu’action dans le cadre des procédures d’intégration back-end (IProcs) pour le traitement des données côté serveur. Les mappeurs de données lisent et transforment les données dans des formats adaptés à une utilisation dans les API ou les objets Salesforce. Aaron Costello a constaté que deux des quatre types de mappeurs de données (Extraction et Turbo Extract) n’appliquent pas FLS par défaut et renvoient des données en texte brut de valeurs chiffrées aux utilisateurs non autorisés à les consulter. Salesforce a attribué la CVE-2025-43697 à ce problème.

Risques de configuration supplémentaires

Quinze autres modèles de configuration peuvent également avoir de graves conséquences en matière de sécurité pour les clients d’Industry Cloud. Par exemple, les mappeurs de données et les métadonnées IProc sont mis en cache à l’aide d’un mécanisme appelé Scale Cache afin d’accélérer l’exécution ultérieure. Bien que les utilisateurs aient besoin de règles de partage configurées pour exécuter des mappeurs de données ou des IProcs, Aaron Costello a constaté qu’une fois mis en cache, ces composants deviennent exécutables par n’importe quel utilisateur, quelles que soient ses autorisations.

« Malheureusement, aucun paramètre de configuration ne permet d’utiliser Scale Cache tout en respectant les contrôles de sécurité du mappeur de données, constate-t-il. Après des tests approfondis, notamment l’activation du paramètre CheckCachedMetadataRecordSecurity d’OmniStudio, il est apparu que la seule façon d’appliquer les contrôles d’autorisation pour les mappeurs de données est de désactiver complètement le cache d’échelle. » complète-t-il. Les procédures d’intégration ne respectent pas non plus le paramètre « Autorisation requise » ni les règles de partage des mappeurs de données ou autres IProcs qu’elles appellent dans le cadre de leurs actions.

Les actions http sous surveillance

Un autre risque de configuration courant concerne les actions HTTP couramment utilisées dans les IProcs pour communiquer avec des API externes. Si ces API nécessitent une authentification, les entreprises peuvent décider de coder en dur les noms d’utilisateur et les mots de passe, ou les jetons d’accès API, directement dans le corps de l’IProc. Toute personne exécutant une de ces APIs peut également consulter les valeurs codées en dur qui y sont stockées. Dans de nombreux cas, cela inclut les utilisateurs externes, voire les utilisateurs invités, qui peuvent exécuter des IProcs en mode débogage.

FlexCards et IProcs prennent en charge un type de source de données appelé « Actions distantes », qui permet l’exécution de classes Apex. Apex est le langage orienté objet de type Java de Salesforce pour la création d’applications sur sa plateforme. Lorsqu’un composant OmniStudio tente d’exécuter une classe Apex via des actions distantes, la requête est transmise par proxy via la classe Apex BusinessProcessDisplayController, qui inclut une méthode GenericInvoke2NoCont. Cette méthode ne vérifie pas si l’utilisateur appelant est autorisé à accéder à l’action distante. « Cela entraîne un contournement des autorisations, ce qui peut donner aux utilisateurs internes et externes la possibilité d’exécuter du code Apex puissant, exécuté sans partage ou sans mesures de sécurité telles que FLS », a déclaré le responsable ajoutant qu’il s’agit du comportement par défaut.

Pack de données et OmniOut dans le viseur

Les packs de données, qui permettent d’exporter et d’importer des composants vers d’autres instances Salesforce, constituent une autre fonction susceptible d’exposer des informations sensibles. Celle-ci laisse des artefacts sous forme de fichiers de définition JSON pouvant contenir des objets dépendants, tels que des IProcs, eux-mêmes contenant des mappeurs de données. « Un utilisateur disposant de droits d’accès en lecture sur cet objet et de règles de partage excessivement larges pourra télécharger les fichiers JSON du composant Pack de données stockés dans le sObject « Pièce jointe » », a précisé Aaron Costello. « Notamment, comme ces pièces jointes reposent uniquement sur des contrôles d’accès au champ « Id » de l’OmniDataPack, les utilisateurs n’ont besoin d’aucune autorisation au niveau du champ sur l’objet « OmniDataPack » pour accéder à ces fichiers, mais uniquement d’autorisations au niveau de l’objet et de la règle de partage. » Les packs de données peuvent également devenir orphelins, par exemple si l’utilisateur qui les crée clique sur le bouton Annuler pendant le processus. Dans ce cas, leurs pièces jointes sont créées et ne sont jamais supprimées. Pire encore, elles ne sont pas répertoriées dans la page d’inventaire des packs de données d’OmniStudio, ce qui complique leur détection par les administrateurs.

Lorsqu’ils sont intégrés à un site web externe, les composants FlexCard ou OmniScript nécessitent un jeton d’accès pour accéder à Salesforce. Ces tokens doivent être créés à l’aide d’une application OmniOut. Cependant, l’utilisateur final d’un site web peut inspecter les requêtes API localement dans son navigateur et extraire ce jeton, qui peut ensuite être utilisé à mauvais escient. Le chercheur recommande aux entreprises d’utiliser un proxy pour la communication entre les composants externes d’OmniStudio et Salesforce. Un proxy, cependant, ne sera d’aucune utilité lorsque le jeton lui-même est intégré à du code OmniOut compromis ou stocké dans des systèmes de contrôle de version publics comme GitHub. De plus, un proxy peut présenter des risques s’il est mal configuré pour transmettre les requêtes sans validation, car les utilisateurs pourraient tenter de falsifier les paramètres et les valeurs.

« OmniOut s’appuyant généralement sur des API Salesforce authentifiées, cette exigence de compte est satisfaite en fournissant au composant OmniOut un jeton d’accès d’application connectée qui sera utilisé pour effectuer des requêtes au nom de tous les utilisateurs externes », a noté le chercheur. « Bien que cela ne soit pas explicitement indiqué dans la documentation Salesforce détaillant le processus de création d’application connectée, il est impératif que les entreprises ne génèrent pas de jeton d’accès pour OmniOut lié à un compte privilégié tel qu’Administrateur système.»

Enfin, les OmniScripts, qui relient plusieurs opérations back-end via des IProcs, des Data Mappers et des FlexCards, disposent d’une fonctionnalité appelée « Session enregistrée » qui propose aux utilisateurs d’enregistrer leur progression et de revenir ultérieurement au script. Lorsque ces sessions sont générées, un enregistrement est créé dans le sObject OmniScript Saved Session, avec toutes les données saisies ou renvoyées par le script jusqu’à leur enregistrement. Par défaut, ces sessions enregistrées n’ont pas de délai d’expiration. « Bien que les utilisateurs invités et/ou des sites communautaires ne puissent pas enregistrer leurs propres sessions, cela ne les empêche pas de consulter les données des sessions d’autres utilisateurs s’ils en disposent, ce qui fait de ce vecteur d’attaque un risque exploitable par des identités internes et externes », a constaté le chercheur.

Pistes d’atténuation

Pour les configurations non sécurisées que Salesforce n’a pas encore corrigées, AppOmni fournit des recommandations d’atténuation dans son article, notamment une liste dont les configurations d’objet, de champ et de règle de partage doivent être régulièrement auditées. Réduire le niveau d’accès aux sObjects OmniStudio et à leurs enregistrements au strict nécessaire constitue la première ligne de défense, a déclaré l’entreprise.