Checklist de la security review Salesforce : quoi corriger, et dans quel ordre

Une checklist de security review Salesforce n'est utile que si elle est ordonnée. La plupart des soumissions échouent sur une courte liste prévisible, et le contrôle d'accès en tête. Travaillez dans cet ordre : appliquez l'accès en mode utilisateur dans le code, triez les trois rapports de scanners, puis réunissez le dossier de soumission et un environnement de test que le relecteur peut réellement utiliser. Salesforce annonce 4 à 5 semaines pour une revue, donc un refus vous coûte un cycle de release, pas un après-midi.

Tekunda a conduit des managed packages jusqu'au bout de la revue dans la santé, la logistique et l'industrie. Ce qui suit est l'ordre dans lequel nous travaillons, pas une description du processus. Pour le parcours de soumission complet, voir How ISVs Pass the Salesforce AppExchange Security Review.

La checklist en un coup d'oeil

1. Confirmez ce que vous soumettez : un managed package, plus chaque service externe qu'il touche.
2. Corrigez le contrôle d'accès : mode utilisateur, sharing explicite, pas de SOQL injectable.
3. Corrigez la gestion des sorties, les secrets, la sécurité du transport et l'authentification.
4. Lancez Code Analyzer, le scan de code du Partner Security Portal et un scan DAST.
5. Corrigez ce qu'exige le seuil de chaque scanner et documentez chaque faux positif.
6. Préparez la documentation, les identifiants et une org de test fonctionnelle.
7. Soumettez depuis la Partner Console et prévoyez la revue annuelle.

Ce qui a changé en 2026

Trois choses ont bougé cette année, et les anciennes checklists les ignorent toutes.

• La marketplace s'appelle désormais AgentExchange. Salesforce a renommé AppExchange en AgentExchange lors de TrailblazerDX 2026 et y a intégré la Slack Marketplace. Le contenu Trailhead de Salesforce utilise maintenant le nouveau nom, mais la security review reste la porte d'entrée vers un listing.
• La version d'API Apex 67.0 change les valeurs de sécurité par défaut. Selon les architect highlights de Summer '26, les opérations de base de données s'exécutent désormais en mode utilisateur par défaut, les classes sans déclaration de sharing prennent with sharing par défaut, et WITH SECURITY_ENFORCED est supprimé : une classe qui l'utilise encore en v67.0 ne compile pas. Les triggers font exception : ils s'exécutent toujours en mode système.
• Vous lancez vous-même le scan dynamique. Les consignes de préparation de Salesforce recommandent désormais OWASP ZAP ou Burp Suite Enterprise Edition pour les endpoints externes et acceptent le scanner DAST de votre choix. Voir Lancer vos propres scans dynamiques après Chimera pour les outils et le rapport à soumettre.

Étape 1 : Confirmer le périmètre

Salesforce est clair : tous les composants et services de votre solution, où qu'ils soient hébergés, entrent dans le périmètre. Cela couvre le package, tout web service qu'il appelle, tout site qui stocke des données Salesforce et tout client mobile ou desktop. Fixez votre type de package avant de corriger le code, car il détermine ce que vous téléversez ; l'article Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged traite ce choix.

Étape 2 : Corriger dans l'ordre les constats qui font refuser les soumissions

Corrigez de haut en bas. Les premiers points sont à la fois les constats les plus fréquents et les plus coûteux à rattraper, et c'est pourquoi les laisser pour la fin fait glisser une soumission d'un cycle.

1. Un contrôle d'accès non appliqué en mode utilisateur. Chaque requête et chaque opération DML doit respecter les droits sur les objets, la sécurité au niveau des champs et le sharing de l'utilisateur courant. Ne vous reposez pas sur la seule valeur par défaut de la v67.0 : un package contient en général des classes sur d'anciennes versions d'API, et les handlers peuvent être appelés depuis un trigger en mode système. Définissez explicitement le mode d'accès avec WITH USER_MODE en SOQL et AccessLevel.USER_MODE sur les appels Database, et remplacez tout WITH SECURITY_ENFORCED restant avant de monter la version d'API.
2. Un sharing déclaré sur les mauvaises classes. Avant la v67.0, une classe sans mot-clé de sharing hérite de celui de l'appelant, donc un helper appelé depuis une méthode @AuraEnabled peut s'exécuter sans sharing sans que personne s'en aperçoive. Déclarez with sharing, without sharing ou inherited sharing explicitement sur chaque classe, y compris internes et utilitaires, pour que le relecteur n'ait jamais à deviner quelle valeur par défaut s'applique.
3. Du SOQL dynamique assemblé à partir d'une entrée. Utilisez des variables de liaison. Si une requête doit vraiment être construite en chaîne, échappez chaque valeur insérée et gardez cet échappement visible dans la même méthode, car c'est là que le relecteur le lit.
4. Une sortie non échappée. Tout ce qui arrive dans la page via escape="false", lwc:dom="manual" ou innerHTML doit être assaini avant, pas après.
5. Des secrets et des données clients au mauvais endroit. Des clés en dur dans l'Apex, des jetons dans des custom settings non protégés, un enregistrement contenant des données personnelles passé à System.debug. Les relecteurs attendent à la place des Named Credentials et des custom metadata protégées.
6. Un chiffrement faible du transport ou du stockage. La liste des constats les plus fréquents de la revue publiée par Salesforce exige TLS 1.2 sur les connexions impliquant vos sites et portails, et l'équipe scanne chaque endpoint externe pour le vérifier. Chiffrez aussi tout ce que vous stockez hors plateforme.
7. Des systèmes externes authentifiés par identifiant et mot de passe stockés. Utilisez OAuth pour chaque connexion que votre package ouvre vers un service que vous ou le client exploitez. Des identifiants stockés sont un constat à eux seuls, et ils rendent le document de flux de données plus difficile à défendre.
8. Un composite site livré sans les bases. Si votre solution inclut une surface web hors de l'org, elle a besoin d'en-têtes de sécurité, et ses cookies doivent porter Secure et HttpOnly. Les relecteurs vérifient le site que vous leur remettez, pas celui que vous décrivez.
9. Des endpoints externes que personne n'a scannés. Si votre package appelle un service que vous exploitez, ce service est dans le périmètre et nécessite son propre rapport de scan dynamique.
10. Un environnement de test inutilisable pour le relecteur. Une org expirée, un challenge d'identité qui le bloque, ou des objets sans données. Salesforce demande aux partenaires de traiter l'équipe de revue comme un client potentiel qui teste toute la solution de bout en bout, et elle ne peut pas examiner ce qui ne fonctionne pas.

Étape 3 : Lancer les scanners et atteindre le seuil de chacun

Vous devez fournir un rapport Salesforce Code Analyzer, un rapport du scanner de code du Partner Security Portal et un rapport DAST. Le seuil n'est pas zéro constat, et il diffère selon le scanner :

• Salesforce Code Analyzer : corrigez tous les constats et erreurs liés à la sécurité sauf les faux positifs, et ignorez ceux qui ne relèvent pas de la sécurité. Il ne scanne pas les endpoints externes.
• Scanner de code du Partner Security Portal (Checkmarx) : corrigez les constats Low, Medium et High, et laissez les avertissements informatifs.
• Scanners DAST comme ZAP, Burp Suite, Veracode Dynamic Analysis, Intruder et Acunetix : corrigez tout sauf les éléments informatifs et les avertissements, puis joignez une capture prouvant que le bon endpoint externe a été scanné.

Générez le rapport Code Analyzer v5 avec le sélecteur de règles AppExchange, pour qu'il corresponde à ce qu'attend le relecteur. Sur une base de code complexe, l'exécution peut prendre des heures :

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

Les scans obligatoires ont changé plus d'une fois, donc vérifiez les exigences de scan actuelles avant de générer quoi que ce soit.

Étape 4 : Documenter chaque faux positif

Dans nos soumissions, quatre catégories reviennent assez souvent comme de vrais faux positifs pour qu'on les anticipe : des constats de contrôle d'accès sur du code qui applique déjà le mode utilisateur, des constats de sharing sur des classes qui ne sont atteintes que depuis un contexte où le sharing est déjà appliqué, des constats de bibliothèque obsolète déclenchés par une chaîne de version dans une static resource embarquée, et des constats de cross-site scripting réfléchi sur des paramètres qui n'atteignent jamais le DOM.

Avoir raison ne suffit pas pourtant. C'est le document qui fait passer. Salesforce demande un document expliquant pourquoi chaque élément signalé ne présente pas de risque de sécurité, et précise d'être spécifique sur la façon dont vous vous protégez de la vulnérabilité indiquée. Donnez à chaque constat sa propre entrée : scanner et identifiant de règle, fichier et ligne, une phrase décrivant le chemin des données, le contrôle exact qui les protège, et où ce contrôle se trouve dans le package. Un rejet en une ligne revient sous forme de question, et les questions coûtent des semaines. Pour le format de justification et les erreurs qui le font refuser, voir Documenter les faux positifs pour la security review Salesforce.

Étape 5 : Réunir le dossier de soumission

• Une documentation d'utilisation écrite pour que quelqu'un qui n'a jamais vu l'app puisse mener un workflow complet.
• La documentation des flux de données entre l'org Salesforce et chaque composite site, app mobile ou extension de navigateur.
• Tous les rapports de scan, la capture de l'endpoint DAST et le document des faux positifs.
• Une org Developer Edition avec le package installé et des données réalistes.
• Les identifiants de chaque système externe que l'app touche, ou une instance de test hébergée.
• Les liens d'installation et identifiants de tout client mobile ou desktop.

Vous démarrez ensuite la revue depuis la Publishing Partner Console : ouvrez l'onglet Technologies, choisissez Start Review sur votre solution, et complétez les sections contacts, détails techniques, documentation et environnement de test avant le paiement.

Combien de temps dure la security review, et combien coûte-t-elle ?

Salesforce indique qu'une solution met en général 4 à 5 semaines à passer la revue, et que chaque solution payante est soumise à des frais de 999 $ pour la soumission initiale et pour chaque nouvelle tentative. Si l'équipe trouve des vulnérabilités, vous corrigez et resoumettez, ce qui compte comme une autre tentative. Salesforce note aussi que la plupart des soumissions passent à la deuxième tentative. Les deux faits mènent à la même conclusion : faites le travail de contrôle d'accès en premier, car la soumission la moins chère est celle que vous n'avez à faire qu'une fois.

Vous préférez confier la revue à des personnes qui l'ont déjà passée ? Tekunda propose, en tant que partenaire Salesforce, une préparation à la security review AppExchange. Si vous hésitez encore à faire appel à une aide externe, lisez Ce que fait un PDO Salesforce, et quand en recruter un.

FAQ

Les apps gratuites doivent-elles passer la security review ?

Oui. Une solution doit réussir la revue avant d'être listée sur la marketplace. Les frais de 999 $ documentés par Salesforce s'appliquent aux solutions payantes.

La version d'API 67.0 me dispense-t-elle du travail CRUD, FLS et sharing ?

Non. Les nouvelles valeurs par défaut ne valent que pour les classes compilées en v67.0 ou plus, et les triggers s'exécutent toujours en mode système. Déclarez explicitement les modes d'accès et le sharing pour que le relecteur puisse les vérifier ligne par ligne.

Salesforce Code Analyzer suffit-il à lui seul ?

Non. Il faut aussi le rapport du scanner de code du Partner Security Portal, et chaque endpoint externe que votre app appelle nécessite son propre rapport DAST.

Une app Agentforce ou à base d'agents change-t-elle la checklist ?

La même revue s'applique, mais chaque service externe que votre agent peut appeler doit être décrit et scanné. Voir Security review AppExchange des applications agentiques : ce qui change.

La security review est-elle un événement unique ?

Non. Les solutions listées sont en général réexaminées une fois par an, et Salesforce peut demander une revue à tout moment. Les nouvelles versions de package passent par une attestation dans la Partner Console plutôt que par une nouvelle revue : gardez donc la checklist comme barrière de release permanente.