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

La plupart des soumissions AppExchange echouent sur une liste courte et previsible, et le controle d'acces arrive en tete. Traitez cette checklist dans l'ordre, d'abord l'application des droits en user mode, ensuite le tri des resultats de scan, enfin les elements du dossier, et vous eliminez la majorite des motifs de renvoi d'un package. Salesforce annonce 4 a 5 semaines pour une revue type, donc un refus coute un cycle de release, pas un apres-midi.

Tekunda a fait passer des managed packages par la security review AppExchange dans la sante, 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 a la security review Salesforce ?

Corrigez de haut en bas. Les points du haut sont les constats les plus frequents et les plus couteux a rattraper, et c'est pour cela que les garder pour la fin fait glisser une soumission d'un cycle.

1. Un controle d'acces qui n'est pas applique en user mode. Chaque requete et chaque operation DML de votre package doit respecter les permissions d'objet, la securite au niveau des champs et le partage de l'utilisateur courant. Preferez WITH USER_MODE en SOQL et AccessLevel.USER_MODE sur les appels Database aux chaines de isAccessible() ecrites a la main, faciles a laisser incompletes.
2. Le partage declare sur les mauvaises classes. Une classe Apex sans mot-cle de partage herite du partage de son appelant, si bien qu'un helper appele depuis une methode @AuraEnabled peut s'executer sans, discretement. Declarez with sharing explicitement sur chaque classe, y compris les classes internes et utilitaires.
3. Du SOQL dynamique construit a partir de saisies. Utilisez des bind variables. Si une requete doit vraiment etre construite sous forme de chaine, echappez chaque valeur inseree et gardez cet echappement visible dans la meme methode, car c'est la que le reviewer le lit.
4. Une sortie non echappee. Tout ce qui arrive dans la page via escape="false", lwc:dom="manual" ou innerHTML doit etre assaini avant d'y arriver, pas apres.
5. Des secrets et des donnees clients au mauvais endroit. Cles en dur dans l'Apex, jetons dans des custom settings, un enregistrement contenant des donnees personnelles passe a System.debug. Les Named Credentials et les protected custom metadata sont ce que les reviewers attendent a la place.
6. Des endpoints externes que personne n'a scannes. Si votre package appelle un service que vous exploitez, ce service entre dans le perimetre et exige son propre rapport de scan dynamique.
7. Un environnement de test inutilisable pour le reviewer. Une org expiree, un identity challenge qui le bloque, ou des objets sans donnees. L'equipe utilise votre solution de bout en bout comme un client, et ne peut pas evaluer ce qui ne demarre pas.

Quels resultats de scan sont des faux positifs, et comment les documenter ?

Le seuil n'est pas zero constat, et il differe selon le scanner. Le guide de preparation de Salesforce le detaille :

• Salesforce Code Analyzer : corrigez toutes les erreurs liees a la securite et ignorez les constats qui n'en relevent 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 elements informationnels et les avertissements, et joignez une capture d'ecran prouvant que le bon endpoint a ete scanne.

Depuis que Salesforce a retire le scanner heberge Chimera le 2025-06-16, vous lancez ce scan dynamique vous-meme. Voir Lancer vos propres scans dynamiques apres Chimera pour les outils acceptes et le rapport a soumettre.

Sur nos soumissions, quatre categories reviennent assez souvent comme de vrais faux positifs pour qu'on les anticipe : des constats de controle d'acces sur du code appliquant deja le user mode, des constats de partage sur des classes atteintes uniquement via un contexte ou le partage est deja applique, des constats de bibliotheque obsolete bases sur un numero de version present dans une static resource embarquee, et du cross-site scripting reflechi sur des parametres qui n'atteignent jamais le DOM.

Avoir raison ne suffit pas : c'est le document qui passe. Salesforce demande un document expliquant pourquoi chaque element signale ne constitue pas un risque de securite et precise qu'il faut etre specifique sur la maniere dont vous vous protegez de la vulnerabilite indiquee. Donnez a chaque constat sa propre entree : scanner et identifiant de regle, fichier et ligne, une phrase decrivant le chemin de la donnee, le controle exact qui la protege, et l'endroit ou ce controle se trouve dans le package. Une refutation en une ligne revient sous forme de question, et les questions coutent des semaines. Pour un guide detaille 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 redigee pour que quelqu'un qui n'a jamais vu l'application puisse derouler un workflow complet.
• La documentation des flux de donnees 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 installe et un jeu de donnees realiste.
• Les identifiants de chaque systeme externe touche par l'application, couvrant les acces API, OAuth et SAML.
• Les liens d'installation et identifiants des clients mobiles ou bureau.

Combien de temps prend la security review et combien coute-t-elle ?

Salesforce indique qu'une solution met generalement 4 a 5 semaines a franchir la revue, et que pour chaque solution payante vendue sur la marketplace des frais de $999 s'appliquent a la premiere soumission comme a chaque tentative suivante. Les deux faits pointent dans la meme direction : traitez le controle d'acces en premier, car la soumission la moins chere est celle qu'on ne fait qu'une fois.

Si vous packagez un produit et preferez confier la revue a une equipe qui l'a deja 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 distribuee sur la marketplace doit passer la revue avant d'etre publiee. Les frais documentes par Salesforce concernent les solutions payantes.

Salesforce Code Analyzer suffit-il a lui seul ?

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

Quelle est la cause de rejet la plus frequente ?

Le controle d'acces. Les requetes et le DML executes en system mode, et les classes qui heritent du partage au lieu de le declarer, generent plus de constats que tout le reste.

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

La meme security review s'applique aux solutions agentiques. La difference se joue sur la documentation des flux de donnees, car chaque service externe que votre agent peut appeler doit etre decrit et scanne.