Dans le paysage numérique hyper-interconnecté d’aujourd’hui, des communications transparentes entre les systèmes deviennent de plus en plus essentielles au fonctionnement efficace des opérations commerciales. Les intégrations personnalisées constituent un excellent mécanisme pour les communications sortantes vers des applications distribuées depuis Salesforce, mais qu’en est-il lorsque ces systèmes doivent renvoyer des données vers Salesforce, en temps réel ?

Pour l’une des nombreuses raisons possibles, il ne nous sera peut-être tout simplement pas possible de modifier ces systèmes externes afin d’utiliser les API Salesforce existantes pour renvoyer les données dans Salesforce. Dans ces scénarios, les webhooks viennent à la rescousse.

‍

‍Qu’est-ce qu’un webhook ?

Les webhooks peuvent être considérés comme une méthode de communication sans intervention entre les systèmes, renversant le paradigme traditionnel des intégrations. Un webhook est un type d’API piloté par un événement plutôt que par une requête, par exemple la création ou la mise à jour d’un enregistrement.

En termes simples, les webhooks sont un mécanisme permettant à un système d’alerter un autre système lorsqu’un événement s’est produit, permettant au système d’écoute de répondre en conséquence. Dans le cas de Salesforce, cela implique d’exposer une URL capable d’écouter, de recevoir et de gérer passivement l’événement de l’autre système.

‍

Configurer un webhook

La configuration d’un webhook à partir de Salesforce peut être une tâche légèrement déroutante la première fois, car il n’y a pas de zone spécifique dans la configuration où nous pouvons le faire. Cependant, en tirant parti des sites Salesforce ou Experience Cloud, nous pouvons fournir une URL accessible publiquement au système externe qui ne nécessite pas d’authentification.

Passons en revue les étapes de base pour configurer un webhook à l’aide d’un site Salesforce :

1. Dans Configuration, utilisez la Recherche rapide pour accéder à la section « Sites et domaines > Sites ».
2. Créez un nouveau site en lui fournissant un label en rapport avec le webhook que vous souhaitez mettre en place. Tout le reste peut être laissé tel quel.
3. Prenez note du « Nom de domaine » et du « Chemin » du site dans la liste « URL personnalisées », car ils seront utilisés pour appeler le webhook.

4. Créez une classe Apex pour agir en tant que gestionnaire de webhook. Il a les exigences suivantes :
   1. Soyez mondial.
   2. Annoté avec @RestResource(urlMapping=’myUrlEndpoint’) qui définit le chemin de l’URL qui appellera ce gestionnaire.
   3. Avoir une méthode annotée avec @HttpPost qui est invoquée lorsque l’URL est appelée. Cette méthode peut soit prendre des paramètres, soit utiliser RestContext pour obtenir le corps de la requête.
   4. Avoir éventuellement un type de retour qui correspond aux données renvoyées à l’appelant.

5. De retour dans les paramètres du site, cliquez sur « Paramètres d’accès Public » et accordez à l’utilisateur invité la permission d’appeler cette classe.
6. Activez le site.

Cela configurera un webhook qui peut être invoqué en effectuant une requête HTTP POST vers « https://sitedomainurl+path/services/apexrest/apexUrlMapping ».

Ces étapes ne couvrent que le strict minimum de la configuration d’un webhook. En pratique, il faut réfléchir plus longuement à la manière dont nous allons traiter les données reçues par le webhook, à sa structure, à la gestion des erreurs potentielles et à la sécurité, qui sont tous des aspects importants de tout webhook.

‍

Sécurité

La configuration d’un site Salesforce ou l’utilisation d’Experience Cloud nous fournit une URL accessible au public qui peut être utilisée pour accéder aux données et appeler des automatisations au sein de l’organisation. En tant que telle, elle doit être traitée avec une extrême prudence comme des erreurs non seulement dans la configuration des autorisations, mais aussi dans la configuration des autorisations. De plus, le code invoqué pourrait par inadvertance divulguer des données d’une organisation.

Nous pouvons prendre plusieurs étapes et considérations pour renforcer notre point de terminaison exposé et améliorer la sécurité de nos webhooks :

1. Contrôle d’accès : l’authentification du webhook peut être une chose délicate à faire, car généralement, de par leur conception, les webhooks ne passent pas par le flux OAuth habituel, ou similaire, pour obtenir une session authentifiée. Cela ne signifie pas nécessairement que nous ne pouvons pas limiter l’accès à notre point de terminaison, mais que nous pouvons utiliser des approches alternatives :
   1. Autorisez uniquement certaines adresses IP à appeler le webhook et à renvoyer une réponse 401 pour les adresses IP inconnues.
   2. Vérifiez le webhook pour l’authentification ou les en-têtes « secrets », indiquant qu’il provient d’un hôte connu.
2. Autorisations du profil d’utilisateur invité : suivez le principe de l’accès le moins privilégié, en accordant à votre utilisateur invité les autorisations spécifiques, et uniquement celles dont il a besoin pour effectuer son travail. Cela réduit considérablement le risque de fuite de données, car le webhook ne peut pas divulguer ce auquel il ne peut pas accéder. Cela peut être augmenté en utilisant un seul site et un seul utilisateur invité par webhook dont vous avez besoin, garantissant ainsi qu’un webhook spécifique ne peut utiliser que exactement ce dont il a besoin.
3. Validation et nettoyage des entrées : étant donné que les webhooks acceptent des données provenant de sources non fiables, nous devons toujours vérifier que les données ressemblent à ce qu’elles devraient (par exemple, si vous mettez à jour un enregistrement de compte, l’entrée inclut uniquement les champs que nous prévoyons de mettre à jour) et nettoyer les données (par exemple, si nous devons interroger un enregistrement basé sur les données du webhook, nous nettoyons les valeurs). La validation et la désinfection peuvent empêcher les types d’attaques les plus courants.
4. Gestion des erreurs : si quelque chose d’inattendu se produit au sein de notre gestionnaire apex, nous devons toujours le monitorer et agir en conséquence. Dans certains cas, nous pouvons rencontrer une erreur récupérable et continuer normalement. D’autres fois, nous pouvons rencontrer quelque chose de complètement inattendu et l’exécution du code ne peut pas continuer. Dans ces cas-là, nous devons toujours détecter l’erreur et renvoyer un statut générique 500, car par inadvertance, ces erreurs non détectées pourraient divulguer le fonctionnement interne de notre code et exposer les données par inadvertance.

Leur intégration dans la configuration de votre webhook peut considérablement renforcer la sécurité de vos points de terminaison exposés et atténuer de nombreux risques potentiels.

Cependant, il est important de souligner que la sécurité est un processus continu et qu’il est crucial de toujours être conscient de tout vecteur d’attaque potentiel et de mettre à jour les pratiques de sécurité au fil du temps.

‍

Résumé

Les webhooks fournissent une méthode de communication unique pour des systèmes disparates qui peuvent facilement faciliter le flux de données vers Salesforce en temps réel. Cependant, il est crucial de donner la priorité à la sécurité lors de la configuration des webhooks et parfois, la planification s’avère vraiment payante en garantissant que vous respectez les principes de sécurité communs, tels que le principe de l’accès le moins privilégié, et que vous évaluez constamment le risque lié à leur utilisation.

Lorsque la sécurité est correctement gérée, il est facile de libérer la puissance de la communication en temps réel et de faire passer vos systèmes au niveau supérieur.

‍

Accelerate Today, Perform Tomorrow !

‍

Sources & Crédits:

• https://blog.cloudanalogy.com/salesforce-integration-with-slack-using-webhook/

‍