App-exchange is the Sales-force app marketplace. The marketplace hosts around 3000 apps 56% of which are a direct revenue source for App development Boston. These apps have been downloaded around 4 million times in the 10-year history of App-exchange 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 Sales-force App-exchange can open new doors won’t be off the mark. Or foolish.
Developing a secure managed package app, and getting it published on Sales force App-exchange, is not an easy task. Passing the Sales-force Security review is no easy feat and require weeks of preparation and re-development. We have helped many organizations get their app published on App-exchange 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 App-exchange Packages and then we went on to discuss how App-exchange 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 App-exchange 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 App-exchange, you need a development strategy. Even though it’s true for most software projects, for Sales-force apps, you need an even more detailed strategy. Even though Comfortableness 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 Sales-force platform follows Open Web Application Security Project (WASP) guidelines on software security and risks. These guidelines focus mainly on making sure that the software integrity, confidentiality, and availability of Sales-force and user resources are not compromised in any way. To know more about the security guidelines highlighted by WASP, 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 Sales-force 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 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 Sales force Review team. Special care must be taken in handling Subjects and S object fields especially when using them in Visual-force pages. You have to make sure that your code does not bypass Visual-force automatic 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.
In addition to CRUD enforcement, Sales-force 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.
This may seem a minor problem for us developers but Sales-force 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 App-exchange 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 Checkmate report. Here are the steps you can take to get the report:
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 Checkmate, proceed to the next tool.
Burp Security Scanner
This is an ever more strict security scanner for App Exchange 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 App Exchange 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 Sales-force 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 App-exchange sooner. Else you might get a long list and it may take weeks to rectify all issues.
For More Information:-