How to pass Salesforce AppExchange Security Review

What is Salesforce AppExchange

AppExchange is an online platform where you can find ready-to-install apps, extensions, and additional services to build up on your Salesforce setup. Product developers distribute their customization solutions with other Salesforce users as AppExchange packages.

‍

Salesforce AppExchange Security Review

In Salesforce, making sure your product is safe is a big deal. Before you can sell your package to the AppExchange audience, it needs to pass a thorough check called AppExchange Security Review. This check is all about how well your product keeps customer data safe and how reliable its protection mechanisms are.

During the Security Review, the Salesforce AppExchange security team looks for weak spots and architectural flaws that can be leveraged by malware to hack and compromise the product and your customers. The Salesforce security team uses standard tests to see if your product can resist these attacks.

Before you submit the solution for a security check, you should properly test it and collect sufficient data about its safety. If the Salesforce AppExchange security team finds weaknesses, they will give you expert advice on improvements, but the product will need to go through another round of paid Security Review.

‍

Stages the ISV Partners need to go through in order to pass the Security Review

‍

‍

Security Review process in a timeline diagram

‍

‍

Security Review Tools

These are the tools we use at Noltic for scanning the code and some third-party services to find any vulnerabilities in our products’ architecture. Plus, a bonus solution that can generate a list of requirements and recommended tools based on the technologies used in your Salesforce product.

‍

Salesforce Code Analyzer (sfdx-scanner)

‍

Starting in Summer '23, it's mandatory to use sfdx-scanner for the Security Review submission. This tool uses code analysis engines such as PMD, ESLint, and RetireJS to inspect your code. It identifies problems – from naming inconsistencies to authentication issues, and provides straightforward, easily understandable results. You can run it through the command line (CLI) or integrate it into your CI/CD process to instantly check the code whenever you make updates.

‍

Checkmarx

‍

Checkmarx is good at keeping software safe. They have the tools to check if your Salesforce solution is secure, and checking the project is quite simple. You just need to provide a username for the org with your solution to the security scanner. The scanner will then review your code and send you an email with the report.

‍

‍

Chimera Scanner

‍

When you have non-Salesforce systems in your app, you might need extra checks. Normally, you need to use either Chimera or ZAP.

Chimera is like a web scanner in the cloud. You can use it for public-facing websites, external services, or APIs that your organization owns. To use it, you need to log in with your PBO account, upload a file called "Abuse Prevention Token" to your web service, and then specify your service URL. Then it checks your web service and provides a report.

‍

ZAP

‍

ZAP, short for "Zed Attack Proxy", is an open-source application designed for finding and fixing security vulnerabilities in web applications. It's a powerful tool that helps developers and security professionals identify potential weaknesses in their web applications. ZAP works by simulating attacks on a web application to discover vulnerabilities and other security issues. Once these issues are identified, ZAP provides detailed reports and recommendations. Zap is used for public-facing websites, external services, or APIs that your organization doesn’t own.

‍

CheckBuider

‍

If you want to get started quickly, try out CheckBuilder. It can help you quickly generate a list of requirements and tools according to the technologies that are used in the project.

‍

What to look for in scan results

‍

Certain security scan results fall into categories that don't need documentation or code modifications. These categories are standard in most of the security scanners we use for security reviews. Some, however, require adjustments before AppExchange Security Review submission.

‍

‍

Common Vulnerabilities and Recommendations

There are a lot of issues you can encounter when scanning your application. Here are 5 common vulnerabilities including examples and recommendations on how to deal with them.

‍

1. Apex insecure endpoint

‍

That means that HTTP protocol was used instead of HTTPS somewhere in the code.

‍

Example

‍

  public without sharing class IntegrationService {
      void callApi() {
          HttpRequest req = new HttpRequest();
          req.setEndpoint('http://demo.trird-party-service.com');
      }
  }

‍

Recommendation

‍

Always use HTTPS (the secure version of HTTP) when connecting with services. This encryption method keeps your data safe as it travels over the internet.

‍

2. Insecure storage of sensitive data

‍

You shouldn't put secret stuff directly into the source code. Even if the code is hidden in a managed package, there are good reasons why this isn't a secure way to do things.

‍

Example

‍

  public with sharing class IntegrationService {
      private static final String TOKEN = '14235332';
  }

‍

Recommendation

‍

Use Protected Custom Metadata Types – if the creds are not dynamically generated, then you can pass them as custom metadata records as well. Right now, they can not be changed or updated through code, but you can access them through query. This way, you don't have to use any post-install script. An Upgradable type of metadata would be best. They can be upgraded through the new release of the package.

‍

3. Apex Sharing Violations

‍

By default, an Apex class can read and change all the organization's data. Since these rules aren't strict, Apex developers must be careful not to accidentally reveal confidential data that's usually hidden from unauthorized users. This happens when you create Apex classes without adding the "with sharing" or "inherited sharing" keywords in the class header, essentially breaking the organization's data-sharing rules.

‍

Examples

‍

  public without sharing class SimpleService {
      //some code here
  }

  public class SimpleService {
      //some code here
  }

‍

Recommendation

‍

Just go through all your Apex classes and make sure you have either "with sharing" or "inherited sharing" specified in the class header. If you come across cases where a class needs to operate without following the usual sharing rules, document why this is necessary and add it to false positives. It's a good idea to also add comments to let other developers know why this approach has been chosen.

‍

4. SOQL Injection Vulnerability

‍

SOQL injection happens when the application takes what the user puts in, and uses it in a dynamic SOQL query. If the input isn't checked properly, it can include SOQL commands that change the query and make the application do unintended things.

‍

Example

‍

  public with sharing class SearchController {

      public static List<Contact> getContacts(String name) {
          String q = 'SELECT Id, Name, Phone ' +
                     'FROM Contact ' +
                     'WHERE Name LIKE \'%' + name + '%\'';

          return Database.query(q);
      }
}

‍

Recommendation

‍

The best way to protect your system is by using String.escapeSingleQuotes(stringToEscape) or bind variables. These methods make sure that the information users provide doesn't break the way your system works. Just make sure users only give input for field names, table names, and the WHERE clause in your queries, and nothing else.

‍

5. CRUD/FLS Vulnerability

‍

These vulnerabilities appear when we don't check that we can access, create, delete, or update objects or fields before we perform DML operations or during run database queries.

‍

Examples

‍

  public with sharing class AccountService {

      public Id createAccount(String name) {
          Account theAccount = new Account(Name = name);
          insert theAccount;

          return theAccount.Id;
      }
  }

  public with sharing class AccountSelector {

      public List<Account> getAccountsByIds(Set<Id> ids) {
          return [SELECT Id, Name, Phone FROM Account WHERE Id IN :ids];
      }
  }

‍

Recommendation

‍

Before you carry out actions like making CRUD operations or querying data, it's important to implement checks regarding CRUD permissions and Field-Level Security (FLS). You can do this by using methods provided by Schema.DescribeSObjectResult and you can use the WITH SECURITY_ENFORCED keyword or the Security.stripInaccessible to make sure you're following security rules.

‍

False Positives Document

Sometimes, when a security-checking tool or a person who reviews your code looks at it, they might find something that seems like a security problem. But in reality, it's not a real issue, because it can't be exploited or because we've already taken care of it somewhere else. We call these kinds of things false positives.

When dealing with false positives, you should write a document that explains why they are not actual problems. You need to describe what your code is doing and why it's not connected to the issue that the scanning tool pointed out. It's a good idea to give examples and cases to prove there's no actual security problem. This will help prevent the Security Review team from asking for extra details that could slow down the approval of your solution.

‍

Example

‍

‍

Additional resources

We already know that Salesforce Trailhead is always a good way for any kind of investigation and helps get up to speed quickly. There are a couple of trails worth pointing out.

‍

Develop Secure Web Apps

‍

‍

AppExchange Security Review

‍

‍

And if you have a little more time,

‍Build Apps as an AppExchange Partner

‍

‍