AppExchange is the Salesforce app marketplace. The marketplace hosts around 3000 apps 56% of which are a direct revenue source for app developers. These apps have been downloaded around 4 million times in the 10-year history of AppExchange and generate $1.5 Billion in revenue per year just on the marketplace alone without counting the subscription based revenue generated by most apps per year. To say that getting your app published on Salesforce AppExchange can open new doors won’t be off the mark. Or foolish.
– Oliver Hansen (@nesensa) March 30, 2016
Developing a secure managed package app, andgetting it published on Salesforce AppExchange, is not an easy task. Passing the Salesforce Security review is no easy feat and require weeks of preparation and re-development. We have helped many organizations get their app published on AppExchange and in each case we have seen that passing the security review is tougher than developing the app itself, especially if you are going to use the app for integrating with third party services or servers, or if you are going to launch the app as a paid variant.
More than a year ago, we talked about different AppExchange Packages and then we went on to discuss how AppExchange is an awesome platform for software makers, especially those targeting B2B segment. 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.
Preparations Before The Security Review
If you need to publish an App on AppExchange, you need a development strategy. Even though it’s true for most software projects, for Salesforce apps, you need an even more detailed strategy. Even though Salesforce.com checks an app on multiple parameters like app’s use case, partner history, organization size, data handling, code structure, etc., its main check is on security issues. Thus most of your planning comes down to making sure that your app is secure.
The Salesforce platform follows Open Web Application Security Project (OWASP) guidelines on software security and risks. These guidelines focus mainly on making sure that the software integrity, confidentiality, and availability of Salesforce and user resources are not compromised in any way. To know more about the security guidelines highlighted by OWASP, check out this PDF.
It’s important that you understand the concepts given in this document as they would be applied completely in the security review process. Understanding these concepts are the first steps in creating a secure app architecture which in turn will help you create a more secure app, which in turn will fast track your app approval. This is important.
Next step is to go through the Salesforce coding guidelines. You can check them out here:
Out of these the most important issues for the app that most app developers face are related to:
Enforcing CRUD and FLS (Force.com)
Enforcing proper Create-Read-Update-Delete (CRUD) permissions and maintaining Field Level Security (FLS) on the objects are one of the most if not the most common problem highlighted by Salesforce Review team. Special care must be taken in handling SObjects and Sobject fields especially when using them in Visualforce pages. You have to make sure that your code does not bypass Visualforce automatic CRUD and FLS enforcement.
More about it here : http://wiki.developerforce.com/index.php/Testing_CRUD_and_FLS_Enforcement
Cross-Site Scripting, or code injection, is a security loophole that allows attackers to insert JS, HTML, or there code type of code into the web page, gaining access to sensitive data, or hijacking sessions. You can prevent it by following proper guidelines and coding procedures.
More about it here: http://wiki.developerforce.com/index.php/Secure_Coding_Cross_Site_Scripting
In addition to CRUD enforcement, Salesforce App developers also need to ensure proper access to data itself. APEX classes can bypass built-in user permissions and field level security restrictions. By default APEX classes can read and update within the instance, therefore special care must be taken care in making sure that your Apex classes do not expose sensitive data that would have been otherwise not available to a particular user of the instance.
More about it here : http://sforce.co/2btuBBP
This may seem a minor problem for us developers but Salesforce takes it seriously. The unused code can expose your app to security attacks, and it increases the App size so it is a genuine concern. We all use a variety of coding technique and in the process of development, we all tend to generate a lot of code that is ultimately not used anywhere. A class that we created for something but is not used anywhere, commented lines of code, functions that are just sitting ideal, controllers that don’t control anything, pieces of code that you wrote to debug some functionalities, etc. These all would have to go. So before going to security review, check your app with a fine tooth comb and remove all unwanted code lines.
Checking Using Automated Tools
Once you have prepared your apps as securely are you can, it time to test it using automated tools and services. These services give back reports that are in turn used in AppExchange app submission processes, so you would have to do it anyway. Passing these tools would significantly decrease your app’s review time.
The first is the Checkmarx report. Here are the steps you can take to get the report:
- Go to the URL http://security.force.com/security/tools/forcecom/scanner and enter the username of your Development org
- This will scan all the force.com component (Apex, visualforce Page).
- Analyze this report, and take action on all the problem points highlighted by the report.
- Once the issues are addressed and you get a clean chit by Checkmarx, proceed to the next tool.
Burp Security Scanner
This is an ever more strict security scanner for AppExchange apps. You would have to purchase an account for it. Here are the steps you can take to get your Burp Scanner Report:
1.Purchase the Burp license for the Burp scanning process of your app.
2. Create a new developer org and install the managed packed in the new developer Org. You can use the original org as well but it’s recommended to use a fresh install.
3. Once Burp scanner completes the scanning process, the report will be generated for the App.The report will be in .html format.
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:
Submitting For The Review
Now that your app has cleared all tests, it’s time to submit it for the review. Log in to the Partner Portal and click on the Publishing tab. Once there click on the Packages tab. From the type of AppExchange app package, you want to publish and then proceed with the next procedures. You would be prompted to submit the security reports we have generated earlier. You may also have to pay for the security review (if you are applying for a Paid Managed Packaged App). This process of submitting the app for review is a 9 Step procedure.
Once you have submitted your app for Security review, you need to submit a case on Salesforce Support. This will again expedite your review process.
Once you have submitted the review, within two or three weeks you will get your first security report. It will have a list of security issues, where you can find them in your code, and how you can rectify it. If you have followed all the process and security guidelines, your re-do list would be very short and your app would be on the way to AppExchange sooner. Else you might get a long list and it may take weeks to rectify all issues. All the best!
References: owasp.org, developer.salesforce, wiki.developerforce
The following two tabs change content below.