Selon Varonis Threat Labs, ces risques ne sont pas l’apanage des grandes entreprises. Dans la mesure où le code Apex est intégré dans de nombreuses applications « prêtes à l’emploi », les entreprises de toutes tailles et de tous secteurs qui sont menacées.
Si elles venaient à être exploitées, ces vulnérabilités pourraient causer des pertes et la corruption des données, ainsi que des dysfonctionnements dans les opérations commerciales de Salesforce. C’est pourquoi il est essentiel de garder une trace des classes Apex et de leurs propriétés, de savoir qui peut les exécuter et comment elles sont utilisées.
Dans le cadre du modèle de responsabilité partagée, ce sont les clients de Salesforce, et non Salesforce à qui incombe la responsabilité de la sécurité du code Apex qu’ils mettent en œuvre. Dans la mesure où ce sont eux qui exploitent Apex, c’est à eux qu’il revient de corriger les classes, les déclencheurs ou le code Apex qui exposent les vulnérabilités.
Les vulnérabilités d’Apex

Le code Apex peut être exécuté dans deux modes différents :
• « Without sharing » - ce mode signifie que le code Apex ignore les autorisations de l’utilisateur. Le code peut accéder à n’importe quel enregistrement et effectuer des modifications.
• « With sharing » - ce mode signifie que le code Apex respecte les autorisations de l’utilisateur au niveau de l’enregistrement, mais ignore les autorisations au niveau de l’objet et du champ.
Les vulnérabilités et les mauvaises configurations peuvent avoir des répercussions catastrophiques. Les équipes de sécurité des entreprises concernées ont attribué un degré de gravité élevé ou critique à bon nombre des vulnérabilités découvertes.

Limiter la casse
Apex est un élément essentiel de Salesforce. Pour améliorer la sécurité de votre instance Salesforce, vous devez absolument vérifier les différentes classes Apex que vous possédez et mettre particulièrement l’accent sur celles qui s’exécutent « without sharing ».
Même si cette opération puisse être effectuée manuellement, elle requiert un investissement considérable en termes de temps et d’efforts.
Salesforce propose diverses méthodes pour renforcer la sécurité de votre code interne, et notamment une manière sécurisée d’intégrer les entrées utilisateur dans les requêtes SOQL.
Une stratégie de sécurité complète doit garantir que les classes Apex ont été examinées par des professionnels de la sécurité et pas seulement par des développeurs ou des administrateurs Salesforce. C’est généralement vrai pour les codes intégrés dans un package AppExchange, mais ce n’est pas toujours le cas pour d’autres codes qui ne font pas partie d’AppExchange. Il en va de même pour le code interne, qui est souvent négligé.
Toute classe Apex vulnérable peut causer des pertes et des corruptions de données. Sachant que les clients de Salesforce sont en fin de compte les seuls responsables de la sécurité du code Apex qu’ils mettent en œuvre, les entreprises doivent gérer en toute sécurité les classes Apex et leurs propriétés, les personnes autorisées à les exécuter et la manière