Preparing for Salesforce AppExchange Security Review!

This post is for guys who are planning to release their app on App Exchange and are looking forward to clearing the security review in one shot! This post aggregates all the good links and information you should have in hand.

Pointers for getting started!

Please go through the following points to better understand the security review process and expectations.

• Force.com AppExchange & OEM Security Review: This page has all the good links and information one needs to know to implement security correctly. This page gives you a complete idea of various steps and the security review process, so going forward in this post, I will not focus on the process.

• Security Review Cost as of now is $300 for initial review and $150 for subsequent annual reviews. For up-to-date information, please check this link.

• Check out the FAQ page on the Salesforce website.

How to implement security correctly?

Following are the points to follow:

• Make sure you read the Force.com resources list carefully; it is good to have your developers go through this before they start coding.

• For a better understanding of various technical items, please go through the OWASP Top Ten Checklist as well.

• More details on how to implement security are available in Secure Coding Guidelines here. This is a good document on various security risks from force.com standpoint.

• Use the Security Coding Library in Apex to easily CRUD/FLS rules; this is mostly ignored by almost all developers.

• At regular intervals (every few weeks) during development, please execute the following two scanners:

1. Force.com Security Source Scanner: This scanner scans Apex/Visualforce code on various critical security and code quality issues. This is a really useful & highly recommended tool (also available as Eclipse plugin if required); it runs async and gives you a PDF report with issue details and solutions too. 

   • A list of some of those issues is mentioned below; most of these are self-explanatory, and more details for ambiguous ones are available in the Security Coding Guidelines. If the development team takes care of all the below issues, most of your security review hassles will be gone.

     • Reflected XSS        

     • SOQL SOSL Injection

     • Stored XSS

     • Sharing

     • Hardcoding Ids

     • Queries With No Where Or Limit Clause

     • Hardcoding References To Static Resources

     • Test Methods With No Assert

2. Web Application Security Scanner: This tool gives you an easy way to simulate a variety of security attacks like SOQL injection, etc. ISV Partners can request free licenses of this application by filling out the form.

• It's good to occasionally participate in the security quiz available on the website.

Apart from that, once you submit your application for security review, Salesforce will confirm the following items from you: Not all of these items are mandatory but it is good from a quality standpoint if your application adheres to these standards, i.e.

• Triggers are Bulkified: Trigger logic supports trigger.new collection of greater than 1 record. 

• Remove Hardcoded IDs: Classes and triggers do not reference any hardcoded IDs.

• Test Bulk Logic Support:

• Create 100 test records in XLS or CSV.

• Run data loader (for individual trigger type: insert, update, delete).

• Validate that logic was successfully applied to all records.

• Remove System.Debug: Removed all unnecessary system.debug() statements from code (excluding test classes/methods).

• Access Controls: Apex scripts generally run in a system context; that is, the current user’s profile-based permissions, field-level security, and sharing rules are not taken into account during script execution.

• Leverage the “with sharing” keyword when declaring a class to respect sharing rules that apply to current users, unless there is a specific business case to over-ride this. Controllers retrieving user-specified objects should always use sharing.

• XSS & SOQL injection issues in Apex & Visualforce. If you have followed the secure coding guidelines and executed the source code scanner as explained above, then there is no need to worry about this one.

• Do your test cases contain adequate System.assert methods to prove that all your code behaves properly?

Escaping false requires care. If you are using <apex.ouputText /> tag with attribute “escape = false” then please make sure either

• The value being printed is some fixed, non-user-inputted text like:

<apex:outputText escape="false" value="{!"<!DOCTYPE html>"}"/>

• Otherwise, value is being escaped via Apex, etc., using Security Coding Library escape functions or any other equivalent. For example:

String usertext = ApexPages.currentPage().getParameters().get('usertext');
// the next line encodes the usertext similar to the VisualForce HTMLENCODE function but within an Apex class.
usertext = ESAPI.encoder().SFDC_HTMLENCODE(usertext);

• Lastly, make sure your application works correctly. The Salesforce team would request you to set up an org for them to play with the app!

Any other tips and tricks?

Do you want to add anything I missed here? Please let me know!

References:

• Security Review Guidelines - Salesforce Developer

• Build and Distribute AppExchange Solutions - ISVforce Guide

• Security Review Resources

• OWASP Top Ten

• force.com ESAPI

Let’s Talk

Drop a note below to move forward with the conversation 👇🏻