Andrew Hanna
Andrew Hanna
Les 2GP managés créés depuis des TRIAL Dev Hubs ne peuvent pas être examinés par l’équipe Security Review.
Assurez-vous que votre 2GP managé a été créé avec le Dev Hub de votre Partner Business Org (PBO).
Assurez-vous ensuite d’avoir demandé l’activation de votre PBO afin qu’il puisse passer de l’état TRIAL à l’état ACTIVE.
Vous devez ouvrir un case, sélectionner "Partner Community & AppExchange" comme produit et "Security Review", puis demander l’activation.
Votre soumission doit inclure les résultats de scan d’application web pour les domaines tiers non Salesforce intégrés à votre app.
Ajoutez tous les endpoints non Salesforce dans votre soumission, inclus comme environnement(s) composite(s), et/ou dans les remote site settings de votre org de test Salesforce. Exemple https://testapi.net/
Les domaines/endpoints non Salesforce sont considérés dans le périmètre du Security Review s’ils sont intégrés à votre composant Salesforce d’une quelconque façon, par exemple si votre app effectue des callouts vers eux, s’ils stockent des données Salesforce ou s’ils sont utilisés à d’autres fins comme l’authentification.
Fournissez les résultats de scan de l’un des outils de scan d’application web approuvés pour tous les sites dans le périmètre de la revue.
Fournissez toutes les informations d’authentification nécessaires, comme les identifiants ou clés API, dont l’équipe Security Review pourrait avoir besoin pour tester ces intégrations externes.
Identity challenge est activé sur votre org. Comme solution de contournement, vous devrez ajouter les plages IP Salesforce à une safelist.
Vous pouvez créer une nouvelle org avec les adresses IP autorisées et l’authentification multifacteur MFA désactivée en suivant les étapes dans ce lien.
Sinon, suivez les étapes ci-dessous dans votre org actuelle :
Appliquez le sharing dans vos classes qui accèdent ou modifient les objets Salesforce standard ou personnalisés.
Pour éviter cette vulnérabilité, vous devez déclarer ces classes avec "with sharing".
Remarque : le sharing est appliqué ou non dans la classe qui exécute les requêtes DML. Si une classe with sharing appelle une autre classe "without sharing" qui exécute les requêtes, les objets récupérés ou modifiés le seront sans application du sharing.
La sécurité des objets (CRUD) et la Field Level Security (FLS) sont configurées sur les profils et permission sets, et peuvent limiter l’accès aux objets standard et personnalisés ainsi qu’aux champs individuels. Les développeurs Force.com doivent concevoir leurs applications pour appliquer les paramètres CRUD et FLS de l’organisation sur les objets standard et personnalisés, et dégrader proprement l’expérience si l’accès d’un utilisateur est restreint.
Voici des cas où il peut être acceptable de contourner CRUD/FLS :
Veillez à documenter ces cas d’usage dans votre soumission.
Révéler des informations dans les instructions debug peut aider un attaquant à identifier des vecteurs d’attaque. Les instructions debug sont précieuses pour diagnostiquer les problèmes de fonctionnement d’une application, mais elles ne doivent pas exposer publiquement des informations sensibles ou trop détaillées, notamment PII, mots de passe, clés et stack traces comme messages d’erreur.
Aucune donnée sensible ou PII ne doit être journalisée avec la méthode system.debug.
La plateforme Force.com utilise largement les règles de partage des données. Chaque objet peut avoir des permissions propres indiquant quels utilisateurs et profils peuvent lire, créer, modifier et supprimer. Ces restrictions sont appliquées lors de l’utilisation de tous les contrôleurs standard. Lorsqu’une classe Apex personnalisée est utilisée, les permissions de profil intégrées et les restrictions de sécurité au niveau champ ne sont pas respectées pendant l’exécution. Par défaut, une classe Apex peut lire et mettre à jour toutes les données de l’organisation. Comme ces règles ne sont pas appliquées, les développeurs utilisant Apex doivent veiller à ne pas exposer par erreur des données sensibles normalement cachées par les permissions de profil, la sécurité au niveau champ ou les valeurs par défaut de l’organisation. C’est particulièrement vrai pour les pages Visualforce. Les classes doivent déclarer explicitement with sharing lorsque c’est possible.
Effectuez une revue complète de votre application en utilisant ce guide pour identifier des problèmes similaires.
Dans la plupart des cas, lorsque l’équipe Security Review commence ses vérifications, elle ne peut pas identifier chaque occurrence de chaque type de vulnérabilité. Son rapport contient donc généralement un exemple de chaque type de vulnérabilité trouvé, et il vous revient de rechercher d’autres occurrences similaires dans votre application.
Consultez les ressources de sécurité Salesforce sur les règles de codage sécurisé, les outils et les formations, ainsi que les ressources ISV Security Review pour préparer le processus de Security Review AppExchange.
En plus des tests manuels, exécutez des scans automatisés avec des outils comme
Salesforce Code Analyzer, OWASP ZAP et Checkmarx.
Salesforce Code Analyzer - Overview & Guide
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner
Plus d’informations ici Security Guidelines for Apex and Visualforce Development
Pour des supports de formation plus approfondis et interactifs, consultez
le nouveau trailhead
ISV Security Review
Vous pouvez rester informé des alertes, participer aux discussions et publier des commentaires et questions dans le Security Review Collaboration Group de la Partner Community.
Générez une checklist de soumission personnalisée à votre solution avec le Security Review Submission Requirements Checklist Builder.
Si vous avez soumis une version de package à la revue et qu’elle a échoué avec des retours de l’équipe sécurité, tenez compte de ces deux points importants lorsque vous êtes prêt à planifier le suivi du Security Review.
Planifier une démo pour découvrir comment Serpent peut renforcer votre stratégie Salesforce DevOps dès aujourd’hui. Serpent de Tekunda propose d’excellents outils pour aider vos équipes DevOps, notamment le contrôle de version intégré, les systèmes de déploiement continu et de release, les outils de merge et de nombreux outils de test.
Andrew Hanna
Serpent Team
Tekunda Team
Tekunda Team
Tekunda Team
Andrew Hanna