The AppExchange is the largest marketplace for cloud-based applications worldwide. It provides access to millions of your potential customers and also a completely new way to extend your business. Nevertheless, it may be nerve racking to develop a secure managed package app, and get it published on Salesforce AppExchange. Some preparation steps, like e.g. security review, take up time and efforts to make everything done appropriately. Security review is a ‘must’ to enter the Salesforce`s marketplace called AppExchange. While planning it you have to parse through lots of information, so here are highlights that will help you get listed your application publically.
PREPARATION PHASE
First of all go through the Force.com Requirements Checklist in detail. The most important things we'd like to point out are the following:
Take advantage of the free self-service source code analysis against code developed on the Force.com Platform. Run a free Web Application Security Scan with Chimera or set up ZAP locally to run a Web Application Security Scan against any external web application that is integrated with Force.com.
Passing these tools would significantly decrease your app’s review time.
FAQ: How does the Code Scanner work? How exactly does it check the security of code?
Chimera is a cloud-based security scanning service that combines several open-source security scanning tools into one service. Chimera is powered by and scans from the Heroku cloud platform. Custom-built code then combines and analyzes the results from all scanning tools used and provides a single, actionable security report to you. Chimera makes use of multiple powerful open-source scanning tools. These tools, as well as some of our own, are run against the targets that you own and specify. Chimera then collates, analyzes, and parses all of their results into a cohesive report for analysis by you and your development team. No changes have been made to the source code or behavior of these tools.
FAQ: Do Lightning applications also checked through code scanner or chimera?
Chimera can be used to scan web applications that you own or develop. So, yes, it can scan Lightning applications.
FAQ: Do I need to fix all the vulnerabilities?
It depends on the type of testing performed. In case you are in the Preparation phase and the automated testing is being performed there are some bugs that you can ignore. However, some of them must be fixed anyway. The table below will help you get deeper understanding.
Scanner | Fix | Ignore |
Checkmarx | Any errors classified as Low, Medium, or High. | Informational warnings. |
Chimera | All errors except false positives. | Low-severity warnings that you determine are false positives; explain why in a document with your review materials. |
ZAP | All errors except those listed in the next column. Once errors are fixed, provide a screenshot of the scan with your review materials, to verify the correct external endpoint is being scanned. | These issues, which you can mitigate, but you are not required to fix. Be sure to document any other false positives. |
If the Salesforce team performs testing of your application all the vulnerabilities have to be fixed in any case.
FAQ: How can I scan a mobile application if Chimera does not support it?
You can use ZAP or Burp Security Scanner. Burp Scanner is considered by many developers to be an ever more strict security scanner for AppExchange apps.
To get your Burp Scanner Report the following steps are required:
1.Purchase the Burp license for the Burp scanning process of your app.
2. Create a new developer org and install the managed package in the new developer Org. You can use the original org as well but it’s preferable to use a fresh install.
3. Once the scanning process is completed, the report in .html format will be generated for the App.
4. According to the issue on Burp report, we have to create a False positive report for all the medium and low issues. The false positive report must be in a .doc format and the data should be in the tabular form.
5. Again this report will be used in submitting the apps so you would have to do this anyhow.
You can check out this post to know more about the Burp Security process.
Each time you make changes to your code, you will want to ensure that your unit tests still cover all of your code and that you have followed all the best practices. We would recommend to kick off the source code analyzer each time you perform changes.
Than it is necessary to test your app manually to ensure it meets all review requirements that were not found by tools. More detailed information you can find here: OWASP Testing Guide. All issues found during testing must be fixed on this preparation step.
FAQ: What does "Ensure triggers are bulkified" mean? And how does it look?
At the Preparation stage you also have to Bulkify Your Code or in other words to ensure that your code can properly process more than one record at a time. That means that triggers should operate on List of object records. The following trigger assumes that only one record caused the trigger to fire. This trigger doesn’t work on a full record set when multiple records are inserted in the same transaction. A bulkified version is shown in the next example.
trigger MyTriggerNotBulk on Account (before insert) {
Account a = Trigger.New[0];
a.Description = 'New description';
}
This example is a modified version of MyTrigger. It uses a for loop to iterate over all available sObjects. This loop works if Trigger. New contains one sObject or many sObjects.
trigger MyTriggerBulk on Account (before insert) {
for (Account a : Trigger.New) {
a.Description = 'New description';
}
}
INITIATION PHASE
To pass the next step you have to ensure that your application is enrolled in either the ISVforce or Force.com Embedded program. In case you are not enrolled please contact your ISV Account Executive or log a case in the partner portal. You can initiate security review for your offering by logging into the AppExchange Publishing Console and clicking "Start Review" on your offering.
For existing offerings that are due for a security re-review, you must also submit a case in the Partner Portal.
You will be asked to provide a Test Environment and Documentation for your offering and pay the Annual Listing Fee. The security review team will perform manual and automated application and network security testing. Afterwards you will receive review results.
In case you want other user to see private objects’ data you just have to change the keyword in your code from “without sharing” (by default) to “with sharing”. Use it when declaring a class to enforce the sharing rules that apply to the current user. You can also declare inner classes and outer classes as with sharing as well. The sharing setting applies to all code contained in the class, including initialization code, constructors, and methods but inner classes do not inherit the sharing setting from their container class. Once exception is execute Anonymous and Chatter in Apex which always executes using the full permissions of the current user.
PUBLISHING PHASE
Now, when you succeeded in passing through previous phases, you only have to login to the AppExchange and make your listing live.
Since Salesforce.com reserves the right to conduct random on-site and off-site tests on published offerings it is necessary to watch the offering meets all the all requirements. Otherwise your AppExchange listing may be pulled from public viewing.
CONCLUSION
To round up we would like to highlight that proper preparation and consideration of possible risks ensure a fairly successful and rapid passing of the security review. Below is a checklist the security review is rotated to. It will surely support you at each step of the process.
-
exclude Reverse Proxy based apps;
-
implementation a strong SDLC with security being a core component;
-
implementation appropriate segregation of duties within the test, development and production environments;
-
exclude storing salesforce.com credentials;
-
implementation encryption in transmission and storage;
-
prevention username enumeration;
-
CAPTCHA's usage or other defenses against automated login attempts;
-
exclude login CSRF (forced login);
-
avoid Dynamic SQL;
-
implementation appropriate input validation and URL cleansing to prevent SQL Injection and Cross-Site Scripting (XSS) attacks;
-
all script and style resources must be loaded via static resources;
-
implementation controls to protect the Salesforce Session ID;
-
summarizing the above regex, it ensures that the URL starts with ‘https://’;
-
ensure that Flash security recommendations are followed as described in the following document.