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 clear 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 thru following points to better understand the security review process and expectations

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

• Good video for those who hate reading long text

  

  

  How to prepare for Your AppExchange Security Review

• 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.

• Checkout FAQ page on Salesforce WIKI : http://wiki.developerforce.com/index.php/Security_Review_FAQ

How to implement security correctly ?

Following are the points to follow

• Make sure you read the Force.com Requirements Checklist carefully, its good to give a dose of this to developers before they start coding

  

  . For better understanding of various technical items, please go thru the OWASP Top Ten Checklist also.

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

  • Use Security Coding Library in Apex to easily CRUD/FLS rules, this mostly ignored by almost all developers. More details about it available in this post

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

  • 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 PDF report having issue details and solutions too. List of some of those issues is mentioned below, most of these are self explanatory and more details for ambiguous ones are available in  Security Coding Guidelines. If development team takes care of all the below issues, most of your security review hassles would 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

  • Web Application Security Scanner : This is tool is based on a paid application called Burp Suite. That gives you an easy way to simulate variety of security attacks like SOQL Injection etc. ISV Partners can request for free licenses of this application by filling in the form available on this page : http://security.force.com/webappscanner

• Its good to occasionally participate in Security Quiz available here : http://security.force.com/platformquiz

• Apart from that once you submit application for security review, salesforce will confirm following items from you, not all of these items are mandatory but its really good for quality stand point 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 : Class and triggers do not reference any hardcoded ids.

  • Test Bulk Logic Support

    1. Create 100 test records in xls or csv

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

    3. Validate 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 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 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>"}"/>
      

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

    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);

• For those who are building complex mashup’s this table below has decent details of security issues that can lead to rejection in security review process

  

• Lastly, make sure your application works correctly

  

  Salesforce team would request you to setup and 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 !