Building an app and publishing it on the AppExchange feels daunting. This three-part series walks you through the process. The first part of how to get an app on AppExchange is planning, in which you answer a series of questions and review things to consider. Once you’ve nailed that, you can move forward with part two: development.

Define the Development Plan

Begin with identifying the sprints from Phase 1 requirements. A sprint is a time frame when a specific task must be completed and ready for review. Before doing any Salesforce development, it’s critical to complete the plan for each sprint.

With all the sprints documented, build out a schedule. Be sure to include the required security review process and creating a listing for the product in the Partner portal. As you create the schedule, incorporate standup meetings, weekly meetings, demonstrations, and package release dates. Leave room in the schedule for feedback in each sprint to accommodate changes requested during the demos.

Begin Development

Analyze the requirements for Phase 1 to create a design document based on the requirements. Break down the tasks to define weekly goals for the team. At standup meetings, discuss task status, hurdles, and priorities.

At the end of every week at the weekly status meeting, provide an update for the week and workload for the next week. Resolve any potential barriers to completing the sprints on schedule. Follow the schedule to release the packages with the completed functionality for testing. Define coding best practices and ensure the team follows security review guidelines.

Conduct Testing

You not only want to test your app for bugs, but also verify it works as planned. Testing also gives your app the best chance for passing AppExchange’s security review process.

Create a test plan for the application with test cases for each function or module in the project. Perform testing with the managed beta version of the package after every release. Continue this process until the creation of the managed release.

After completing the main release, test the managed release version. This prevents losing any configurations and optimizes testing time. Share the test results for each version of the package and use a project management tool to track any issues to closure. This tool will ensure that no issues slip through.

Planning for Time-to-Market

Define a timeframe for taking the app to market as a minimal viable product with the fewest features required. Create a schedule for completing product development, marketing activities, and sales activities within the go-to-market timeframe. Incorporate the creation of marketing content in the schedule while Phase 1 is underway. AppExchange requires marketing content upon publishing.

Hold discussions with the AppExchange team to explain the product and the plan for demos. Doing this will help speed up the security review. After completing the scope for the first phase, prepare to develop the first version of the product and publish.

Since the marketing content is done during development, it should be ready to go when the first version is done. Initiate the security review with AppExchange as soon as possible with the minimal viable product to limit delays.

Preparing for Security Review

The detailed security review process helps AppExchange remain a trusted place for cloud applications. Therefore, it requires every app to undergo the security review process to determine whether an app meets security standards and best practices.

The AppExchange team tests all parts of an app to verify there are no risks for customers and their data. If the security review finds any issues, they must be fixed before the app can move forward.

Here are the steps to prepare for security review:

1. Review the Requirements Checklist to validate your app meets them.
2. Scan application code with scanner tools and fix any issues.
3. Use ZAP tool locally to run a Web Application Security Scan to verify integration with external systems.
4. Conduct manual code reviews internally to ensure the app meets Salesforce’s security best practice guidelines.
5. Fix any issues.
6. Repeat steps until all issues addressed.
7. Complete the security review questionnaire.
   • Specify technology used, such as client-side JavaScript, Visualforce pages and Apex classes, external applications, and mobile components.
   • Provide test environment with package installed and configured. The security review will use this to test the app.
   • Attach scanner reports including false positive documents for any of the open issues based on the functionality of the package.

You can expect security review results about six to eight weeks after submission. If the security review team reports any issues, these need to be fixed and the app resubmitted for another security review. This cycle usually repeats two or three times until the app passes the review.

Some of the Common Issues and Fixes

Several issues tend to arise during security review. Check your app for some of these issues to improve your app’s chances of passing.

1. DOM-based Cross-site Scripting (XSS) Vulnerability

Cross-site scripting (XSS) attacks occur when malicious scripts get injected on trusted web sites. An attacker uses web application to send the malicious code, generally in the form of a browser side script, to a different end user.

Fix: Use JavaScript on Visualforce pages specially when displaying data inside script tags. Encode displayed data.

For example, use {!JSENCODE(text)} where text can be a merge field or text string that may contain the unsafe JavaScript characters. This prevents cross-site scripting attacks.

For more information, please see DOM based XSS Prevention Cheat Sheet at https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Example

var varStartTime = "{!JSENCODE(HTMLENCODE(InitiateTime))}";

2. Insecure Storage of Sensitive Data Vulnerability

This issue occurs when sensitive data such as passwords are directly used in Apex controllers.

Fix: Use cryptographic hash function. For more information, please refer to Storing Sensitive Data at https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets?language=en&language=en

Example

//Encrypting UserName
 blob textBlob = blob.valueOf(Username);
 blob encryptedData = Crypto.encryptWithManagedIV('AES256',cryptoKey,textBlob);
 string strEncryptedUserName = EncodingUtil.base64Encode(encryptedData);

3. Sharing Violation Vulnerability

The Force.com platform extensively uses data sharing rules. Each object can have different permissions for a given profile based on whether the users have read, create, edit, and delete access. The restrictions are enforced when using all the standard controllers.

The data will be displayed to the users with the user of different sharing rules defined based on the role hierarchy defined in the system. But when using a custom Apex class, the profile permissions, field-level security restrictions, and sharing rules are not respected during the execution.

Fix: Use the “with sharing” keyword when declaring a new Class.

Example

public with sharing class BatchSMSSummaryReportCC {}

Even when you complete the development process, there will be ongoing development activities after the app is published on the AppExchange. The next post in the series will cover the publishing phase.

How to Get an App on Salesforce AppExchange Series

• Part 1: Plan
• Part 2: Develop (This post)
• Part 3: Publish

Related posts

• How to Export Data in Excel Using Visualforce
• How to integrate Salesforce with Facebook
• Boost Your Message Open Rate With This Salesforce Lightning Tool

To learn about Salesforce application development services, which includes helping your organization get an app on AppExchange, please contact us at customersuccess@appshark.com.