Sécuriser les API REST Salesforce : Named Credentials, flux OAuth et renforcement des endpoints personnalisés

Les intégrations sont le cœur des architectures d'entreprise modernes, mais elles constituent également les vecteurs d'attaque les plus ciblés.

Soyons honnêtes : nous nous sommes tous déjà connectés à une ancienne Org Salesforce pour y trouver une classe Apex contenant une clé d'API codée en dur, une URL de endpoint pointant directement vers un serveur de production, ou une classe personnalisée @RestResource entrante s'exécutant entièrement without sharing sans aucun contrôle CRUD ou FLS.

En tant qu'Architecte ou Développeur Salesforce, écrire du code qui « fonctionne, tout simplement » ne suffit pas. Vos intégrations doivent être sécurisées dès la conception (secure by design). Une seule identité exposée ou un endpoint d'API personnalisé non protégé peut se transformer en une fuite de données massive.

Sécuriser vos API REST implique de protéger les deux faces d'une même pièce : les appels sortants (outbound) qui quittent Salesforce et les appels entrants (inbound) qui exposent les données Salesforce au monde extérieur. Voici votre guide stratégique pour renforcer les deux.

1. Sécurité sortante (Outbound) : Le modèle moderne des Named Credentials

Il y a quelques années, effectuer un appel HTTP consistait à stocker les endpoints dans des Custom Metadata, à sauvegarder les mots de passe dans des Protected Custom Settings et à construire manuellement les en-têtes d'autorisation en Apex. Cette approche est obsolète et dangereuse.

Aujourd'hui, Salesforce sépare la configuration de l'authentification en utilisant les Named Credentials modernes et os External Credentials.

• External Credentials : Gèrent la manière dont vous vous authentifiez (OAuth 2.0, clés d'API, JWT) et associent les permissions aux systèmes externes via des Permission Sets.

• Named Credentials : Gèrent l'endroit que vous appelez (l'URL du endpoint) et font référence à l'External Credential correspondante.

Pourquoi c'est crucial pour la sécurité :

• Exposition zéro des secrets : Le code Apex ne touche jamais au jeton (token) réel, au secret client ou au mot de passe. Salesforce gère le chiffrement, le stockage et la rotation des jetons de manière sécurisée en arrière-plan.

• Maintenabilité : Si un mot de passe ou un secret client OAuth change, vous le mettez à jour dans l'interface utilisateur, pas dans le code. Votre code Apex reste parfaitement propre.

2. Choisir le bon flux OAuth

Lorsque des microservices externes doivent appeler Salesforce, ou lorsque Salesforce appelle des systèmes externes, vous devez sélectionner le bon flux OAuth 2.0. S'appuyer sur l'ancien flux « Username-Password » est fortement déconseillé et obsolète dans toute l'industrie.

Scénario A : Serveur à serveur (Intégrations automatisées)

Lorsqu'un middleware externe (comme AWS EventBridge, un ERP ou une fonction AWS Lambda) doit communiquer avec Salesforce sans intervention humaine, utilisez le flux OAuth 2.0 JWT Bearer.

• Comment ça marche : Le système externe signe un jeton numérique à l'aide d'une clé privée et l'échange contre un jeton d'accès (access token).

• Avantage sécurité : Aucun mot de passe ni secret client n'est envoyé sur le réseau. La sécurité repose entièrement sur un certificat X.509 sécurisé.

Scénario B : Intégrations avec contexte utilisateur

Si une application doit effectuer des actions de manière interactive pour le compte d'un utilisateur spécifique, utilisez le flux de serveur Web OAuth 2.0 (Authorization Code Grant), de préférence associé à PKCE (Proof Key for Code Exchange) pour empêcher les attaques par interception de code d'autorisation.

3. Sécurité entrante (Inbound) : Renforcer les endpoints custom @RestResource

Les endpoints REST Apex personnalisés sont incroyablement puissants, mais ils ouvrent une fenêtre directe sur votre base de données. Par défaut, le code Apex s'exécute en Mode Système, ce qui signifie qu'il contourne la sécurité au niveau des objets de l'utilisateur (CRUD), la sécurité au niveau des champs (FLS) et les règles de partage des enregistrements (Sharing Rules).

Si vous ne sécurisez pas vos endpoints personnalisés, un utilisateur externe authentifié pourrait potentiellement interroger ou modifier des enregistrements dont il ne devrait même pas soupçonner l'existence.

Règle 1 : Imposer les règles de partage (Sharing Rules)

Ne déclarez jamais une classe REST sans spécifier explicitement son comportement de partage. Utilisez toujours par défaut with sharing ou inherited sharing.

Règle 2 : Imposer le CRUD et le FLS automatiquement

Ne vous fiez pas aux vérifications manuelles Schema.sObjectType pour chaque champ — c'est fastidieux et source d'erreurs. Tirez plutôt parti des fonctionnalités modernes de sécurité d'Apex, comme le Mode Utilisateur (User Mode) ou Security.stripInaccessible.

Lorsque vous interrogez ou manipulez des données au sein d'un endpoint d'intégration, utilisez WITH USER_MODE. Si le système consommateur ou le profil utilisateur ne dispose pas des permissions nécessaires pour afficher AnnualRevenue, la requête lèvera une QueryException facile à intercepter, empêchant ainsi la fuite de données sensibles.

4. Se protéger contre les vulnérabilités courantes

Au-delà de l'authentification et du contrôle d'accès, les endpoints personnalisés sont sensibles aux vulnérabilités classiques des applications Web.

Injections SOQL

Si vous concaténez directement les entrées utilisateur (user input) dans des requêtes dynamiques au sein d'un service REST, vous êtes vulnérable aux injections SOQL.

• La méthode dangereuse : String query = 'SELECT Id FROM Contact WHERE LastName = \'' + userInput + '\'';

• La méthode sécurisée : Utilisez toujours des requêtes statiques avec des variables de liaison (Bind Variables). Les variables de liaison sont automatiquement nettoyées (sanitized) par la plateforme, ce qui rend l'injection impossible.

Si vous devez absolument utiliser une requête dynamique, encadrez la chaîne d'entrée en utilisant String.escapeSingleQuotes(userInput).

Validation du Payload et des entrées

Ne supposez jamais que les données entrantes sont propres ou bien formées. Validez vos payloads tôt dans le contexte d'exécution :

• Vérifiez que les champs obligatoires sont présents avant le traitement.

• Imposez un contrôle de type strict et des limites de longueur sur les entrées de chaînes (strings) afin d'éviter les états d'application inattendus ou une utilisation excessive du temps CPU.

Verdict Final

La sécurité des API n'est pas une case à cocher juste avant le déploiement ; c'est un pilier architectural fondamental. En faisant l'abstraction de vos identifiants sortants grâce aux Named Credentials, en choisissant des flux OAuth cryptographiques et en imposant strictement le Mode Utilisateur au sein de votre code Apex, vous éliminez la grande majorité des risques liés aux intégrations.

Restez ferme sur vos périmètres, validez tout et écrivez du code qui part du principe que le réseau est déjà compromis.

Contact

Contactez-nous pour toute suggestion ou question technique.

Email

andre@theforcejournal.tech

© 2026. Tous droits réservés.