Réussir la Security Review Salesforce pour votre package

La Security Review est le passage obligé avant toute publication sur AppExchange. Salesforce y vérifie que votre package ne présente pas de faille exploitable et respecte les bonnes pratiques de développement sécurisé. C'est aussi la principale source de retards pour les éditeurs mal préparés. Voici les points de contrôle qui reviennent le plus souvent et comment les anticiper.

1. Comprendre le déroulement de la review

La Security Review combine une analyse statique automatisée (scan Checkmarx sur votre code Apex, LWC, VisualForce) et, pour les cas complexes, une revue manuelle par un ingénieur sécurité Salesforce. Le processus se déroule ainsi :

1. Soumission du package via le Partner Portal avec la documentation technique (architecture, flux de données externes).
2. Scan automatisé, dont le rapport vous est renvoyé sous quelques jours.
3. Correction des vulnérabilités identifiées et nouvelle soumission.
4. Validation finale, parfois précédée d'un entretien technique pour les cas sensibles (intégrations externes, traitement de données personnelles).

2. Les vulnérabilités les plus fréquentes

Sur la base des retours d'expérience terrain, quelques catégories de failles reviennent systématiquement :

• Injection SOQL/SOSL : concaténation de chaînes non échappées dans une requête dynamique.
• Absence de vérification CRUD/FLS : lecture ou écriture de données sans contrôle des droits de l'utilisateur courant.
• Cross-Site Scripting (XSS) : affichage de données utilisateur non échappées dans un composant Visualforce ou LWC.
• Secrets en dur : clés API, mots de passe ou tokens stockés directement dans le code au lieu de Custom Metadata chiffrés ou de Named Credentials.
• Appels HTTP non sécurisés : absence de validation de certificat ou usage de HTTP au lieu de HTTPS pour les callouts.

3. Corriger l'injection SOQL et les contrôles CRUD/FLS

La règle d'or : ne jamais faire confiance à une entrée utilisateur, et toujours vérifier les droits avant d'accéder aux données.

// Vulnérable : injection possible via la variable searchTerm
String query = 'SELECT Id FROM Contact WHERE Name = \'' + searchTerm + '\'';
Database.query(query);

// Sécurisé : liaison de variable + vérification des droits
if (Schema.sObjectType.Contact.isAccessible()) {
    List<Contact> results = [SELECT Id FROM Contact WHERE Name = :searchTerm WITH SECURITY_ENFORCED];
}

Pour le DML, utilisez systématiquement Security.stripInaccessible() avant une insertion ou une mise à jour lorsque les données proviennent d'une source externe ou d'un composant Lightning exposé.

4. Named Credentials plutôt que des secrets en dur

Tout appel vers une API externe doit passer par une Named Credential ou un External Credential, jamais par une clé codée en dur dans une classe Apex. Les reviewers Salesforce recherchent explicitement ce pattern lors de l'analyse manuelle.

Documentez précisément, dans le formulaire de soumission, chaque endpoint externe appelé par votre package : domaine, protocole, données transmises. Une intégration non documentée est presque toujours source de rejet.

5. Préparer sa soumission pour limiter les cycles

Chaque cycle de correction/re-soumission prend facilement deux à trois semaines. Pour limiter le nombre d'allers-retours :

• Lancez le scan de sécurité gratuit disponible dans le Partner Portal avant la soumission officielle.
• Faites relire votre code par quelqu'un qui n'a pas participé au développement : les biais de familiarité masquent souvent les failles évidentes.
• Tenez à jour un document d'architecture décrivant précisément les flux de données, y compris avec les sous-traitants tiers éventuels.
• Testez vos composants LWC avec des entrées volontairement malveillantes (balises HTML, scripts) pour vérifier l'échappement automatique.

La Security Review n'est pas un obstacle bureaucratique : c'est un filet de sécurité qui protège vos futurs clients et, par extension, votre réputation d'éditeur. Un package qui passe la review du premier coup est presque toujours un package dont l'équipe a intégré ces exigences dès la phase de conception, et non en correction de dernière minute.