Ace the salesforce security review

Sailfin 0 comment

If you are in the Salesforce ecosystem or an ISV vendor planning to submit your app for listing on AppExchange – online marketplace for Salesforce apps, this article could come handy and help you in getting over the line.

At Sailfin Technologies , we have had gathered much experience while publishing applications ImportBuddy and Enterprises Manager on AppExchange. Our team has rigorously worked on vulnerability and penetration testing, to Apex code reviews and scanning, to working with Salesforce to address additional threats that allow us to remain confident that our work will pass the security review.

Sailfin also offers security review engagement to companies so that they can benefit from the expertise. The engagement is intended to develop a custom checklist for security submission, complete security scans, provide best practice guidance for remediating any issues found during preliminary scans, and assist with the documentation of false positives and remediation notes.

Want to expedite your Security Review process? Schedule a consultation with our team today. “Contact Us”.

In this post, we will discuss best practices on getting your app published on AppExchange and how you can fast track the security review process and get your app published on the app-exchange faster.

During “Security Review” a Salesforce security expert looks at the application’s source code as well as any external integrations and attempt to penetrate the defense programmed in the solution with threat-modeling profiles based on common web vulnerabilities. Only after an application passes the security review with zero security findings can it be released onto the AppExchange. Because the quality of the security review submission directly impacts the time it takes to review the application, please plan on 4-6 weeks from the time the app has been submitted to manage expectations accordingly.


Follow OWASP guidelines
Open Web Application Security Project (OWASP) guidelines focus on the technical controls specific to mitigating the occurrence of common software vulnerabilities and making sure that the software integrity, confidentiality, and availability of Salesforce and user resources are not compromised in any way. Understanding these guidelines will help to create better app architecture and make your app more secure, which in turn will fast track your app approval.

Salesforce security review team generally checks for injection (SOQL and SQL), issues with authentication and session management, XSS – Cross-site scripting, CSRF – Cross-site Request Forgery, insecure references to objects, access control, reference vulnerabilities and misconfigured security among other things. A list of OWASP top 10 will be a great reference point to know what will be checked in a security review. Salesforce also offers an interactive tool to generate a personalized list of necessary submission requirements. Refer to the submission requirements checklist builder, found at the bottom on the security overview page.

Enforce CRUD/FLS rules
Enforcing proper Create-Read-Update-Delete (CRUD) permissions and maintaining Field Level Security (FLS) on the objects is an important area highlighted by the Salesforce Review team. Special care must be taken in handling SObjects and Sobject fields especially when using them in Visualforce pages and ensure that code does not bypass Visualforce automatic CRUD and FLS enforcement. It’s important to check for CRUD/FLS settings using the isAccessible() or similar method depending on the DML operation. Wrapping the code in the isAccessible() method gracefully offer an alternative action if an administrator has restricted field accessibility. The easiest way to pass the CRUD/FLS requirement is to implement some open source code called DML Manager.

Access Control
By default, APEX classes can read and bypass built-in user permissions and field-level security restrictions and can read and update within the instance. Therefore, special care must be taken so ensure that Apex classes do not expose sensitive data which otherwise is not accessible to any particular user. Developers should make sure that each class file in the package is using the “with sharing” keywords so that it tells the apex to check for any sharing rules that are configured by the administrator. If you have a valid use case for omitting “with sharing” be prepared with a good reason and add that as a comment to salesforce during the security review process.

Use automated tools
Once the application development has been completed the next step is to submit it to Checkmarx. Checkmarx is a cloud security app that reports on Force.com code related issues. Uploading these scan reports is an important step during the AppExchange app submission. Don’t forget to re-run the scan after fixing the points and submit the latest report during the app submission. Somehow salesforce security reviewers will come to know whether this step has been completed or not, so don’t overlook it. Passing these tools would significantly decrease the app review time.

Write Unit tests with system.assert
Test methods can be effectively written to achieve the desired code coverage without a system.assert statement. However, this is one of the items that the automated Checkmarx system looks for. Make sure to include a system.assert statement in each unit test.

Remove Unused code:
Developers use a variety of coding techniques and generate a lot of code during development that is ultimately not used anywhere. Common mistakes include A class created for something but not used, code-piece written to debug some functionalities, etc. This may seem a minor problem, but Salesforce takes it seriously as unused code can expose your app to security attacks and increases the App size.

Submission Process
After submitting the app for security review, kindly submit a case on Salesforce support to expedite the review process. The first security report may take 2 to 3 weeks to come from Salesforce and that report will have a list of security issues, details of the occurrence, and corrective steps.

If the guidelines mentioned above are followed the re-do list would be very short and the app would be on the way to AppExchange sooner.

As you embark on the security review journey, keep guidelines above in mind to help take you further, faster. And remember, we are always here to help. “Contact Us”.

References: owasp.org, developer.salesforce, wiki.developerforce