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

La plupart des soumissions AppExchange échouent sur une liste courte et prévisible, et le contrôle d'accès arrive en tête. Traitez cette checklist dans l'ordre, d'abord l'application des droits en user mode, ensuite le tri des résultats de scan, enfin les éléments du dossier, et vous éliminez la majorité des motifs de renvoi d'un package. Salesforce annonce 4 à 5 semaines pour une revue type, donc un refus coûte un cycle de release, pas un après-midi.

Tekunda a fait passer des managed packages par la security review AppExchange dans la santé, la logistique et l'industrie. Ce qui suit est l'ordre dans lequel nous travaillons, pas une description du processus.

Qu'est-ce qui fait rejeter une soumission à la security review Salesforce ?

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

1. Un contrôle d'accès qui n'est pas appliqué en user mode. Chaque requête et chaque opération DML de votre package doit respecter les permissions d'objet, la sécurité au niveau des champs et le partage de l'utilisateur courant. Préférez WITH USER_MODE en SOQL et AccessLevel.USER_MODE sur les appels Database aux chaînes de isAccessible() écrites à la main, faciles à laisser incomplètes.
2. Le partage déclaré sur les mauvaises classes. Une classe Apex sans mot-clé de partage hérite du partage de son appelant, si bien qu'un helper appelé depuis une méthode @AuraEnabled peut s'exécuter sans, discrètement. Déclarez with sharing explicitement sur chaque classe, y compris les classes internes et utilitaires.
3. Du SOQL dynamique construit à partir de saisies. Utilisez des bind variables. Si une requête doit vraiment être construite sous forme de 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 reviewer 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 d'y arriver, pas après.
5. Des secrets et des données clients au mauvais endroit. Clés en dur dans l'Apex, jetons dans des custom settings, un enregistrement contenant des données personnelles passé à System.debug. Les Named Credentials et les protected custom metadata sont ce que les reviewers attendent à la place.
6. Des données laissées en clair, au repos ou en transit. AES-256 pour tout ce que vous stockez hors plateforme, TLS 1.2 ou supérieur sur chaque saut. Un callout qui négocie encore une ancienne version de TLS est un constat, même si la charge utile est anodine.
7. Des systèmes externes authentifiés par un identifiant et un 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 site composite livré sans les bases. Si votre solution embarque une surface web hors de l'org, elle a besoin d'en-têtes de sécurité, et ses cookies doivent être Secure et HttpOnly. Les reviewers regardent 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 entre dans le périmètre et exige son propre rapport de scan dynamique.
10. Un environnement de test inutilisable pour le reviewer. Une org expirée, un identity challenge qui le bloque, ou des objets sans données. L'équipe utilise votre solution de bout en bout comme un client, et ne peut pas évaluer ce qui ne démarre pas.

Quels résultats de scan sont des faux positifs, et comment les documenter ?

Le seuil n'est pas zéro constat, et il diffère selon le scanner. Le guide de préparation de Salesforce le détaille :

• Salesforce Code Analyzer : corrigez toutes les erreurs liées à la sécurité et ignorez les constats qui n'en relèvent pas.
• Scan de code du Partner Security Portal : corrigez les niveaux Low, Medium et High et laissez les avertissements informationnels.
• Scanners dynamiques comme ZAP, Burp Suite, Veracode, Intruder, Acunetix et JiT DAST : corrigez tout sauf les éléments informationnels et les avertissements, et joignez une capture d'écran prouvant que le bon endpoint a été scanné.

Générez le rapport Code Analyzer avec le jeu de règles AppExchange, pour qu'il corresponde à ce que le reviewer attend :

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

La liste des scans obligatoires a changé récemment, vérifiez donc les exigences actuelles des scanners avant de générer quoi que ce soit.

Depuis que Salesforce a retiré le scanner hébergé Chimera le 2025-06-16, vous lancez ce scan dynamique vous-même. Voir Lancer vos propres scans dynamiques après Chimera pour les outils acceptés et le rapport à soumettre.

Sur 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 appliquant déjà le user mode, des constats de partage sur des classes atteintes uniquement via un contexte où le partage est déjà appliqué, des constats de bibliothèque obsolète basés sur un numéro de version présent dans une static resource embarquée, et du cross-site scripting réfléchi sur des paramètres qui n'atteignent jamais le DOM.

Avoir raison ne suffit pas : c'est le document qui passe. Salesforce demande un document expliquant pourquoi chaque élément signalé ne constitue pas un risque de sécurité et précise qu'il faut être spécifique sur la manière 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 de la donnée, le contrôle exact qui la protège, et l'endroit où ce contrôle se trouve dans le package. Une réfutation en une ligne revient sous forme de question, et les questions coûtent des semaines. Pour un guide détaillé du format de justification et des erreurs qui le font rejeter, voir Documenter les faux positifs pour la security review Salesforce.

Que faut-il joindre au package dans le dossier ?

• Une documentation d'usage rédigée pour que quelqu'un qui n'a jamais vu l'application puisse dérouler un workflow complet.
• La documentation des flux de données entre l'org Salesforce et tout composite site, application mobile ou extension de navigateur.
• Tous les rapports de scan, plus le document de faux positifs.
• Une org Developer Edition avec le package installé et un jeu de données réaliste.
• Les identifiants de chaque système externe touché par l'application, couvrant les accès API, OAuth et SAML.
• Les liens d'installation et identifiants des clients mobiles ou bureau.

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

Salesforce indique qu'une solution met généralement 4 à 5 semaines à franchir la revue, et que pour chaque solution payante vendue sur la marketplace des frais de $999 s'appliquent à la première soumission comme à chaque tentative suivante. Les deux faits pointent dans la même direction : traitez le contrôle d'accès en premier, car la soumission la moins chère est celle qu'on ne fait qu'une fois.

Si vous packagez un produit et préférez confier la revue à une équipe qui l'a déjà franchie, Tekunda construit et package des produits AppExchange en tant que PDO Salesforce.

FAQ

Les applications gratuites doivent-elles passer la security review ?

Oui. Toute solution distribuée sur la marketplace doit passer la revue avant d'être publiée. Les frais documentés par Salesforce concernent les solutions payantes.

Salesforce Code Analyzer suffit-il à lui seul ?

Non. Code Analyzer v5 couvre l'Apex, la Visualforce, le JavaScript et le TypeScript de votre package. Chaque endpoint externe appelé par votre application exige en plus son propre rapport de scan dynamique.

Quelle est la cause de rejet la plus fréquente ?

Le contrôle d'accès. Les requêtes et le DML exécutés en system mode, et les classes qui héritent du partage au lieu de le déclarer, génèrent plus de constats que tout le reste.

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

La même security review s'applique aux solutions agentiques. La différence se joue sur la documentation des flux de données, car chaque service externe que votre agent peut appeler doit être décrit et scanné.

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

Non. Salesforce réexamine périodiquement les solutions publiées, et chaque fonctionnalité livrée ensuite est tenue au même niveau. La checklist est donc une barrière de release permanente, pas une tâche de lancement.