The tremendous growth and popularity of Salesforce and the extremely fluid nature of the platform as it incorporates the latest developments technology has to offer provides evergreen scope for developing new apps. However, there is a catch when it comes to publishing apps on the Salesforce AppExchange.
Salesforce requires all AppExchange and OEM applications to pass a security review before listing on the AppExchange and/or distribution to any customers. The obvious aim is to develop a culture of trust, by ensuring that all apps meet a set of security standards and other best practices. Failure to pass the Salesforce security review so could lead to major time delays and extra efforts to make the required changes before the app may be rolled out.

Following these tips would help to pass this daunting hurdle:

1. Understand the Process

Salesforce conducts its security review after the developer submits the app to the AppExchange. However, passing the review requires effort from the very start of the application development process.

Developers would do well to:

• Understand how Salesforce carries out the assessment. The security review process comprises of a qualitative assessment, which involves a questionnaire to review policies and procedures; and a quantitative round of entails testing the app for security weaknesses.
• Read the Force.com Requirements Checklist and the Secure Coding Guidelines carefully upfront, to understand the major security risks from Force.com’s standpoint, and incorporate the same in the app. For instance, almost all developers ignore using Security Coding Library in Apex to create CRUD/FLS rules, but Force.com takes it seriously.
• Understand how Salesforce prefers to store keys, secrets, passwords, and other secure data. Among the three key concepts for handling and storing secure data: custom settings, apex crypto functions, and encrypted custom fields. The best practice is a combination of apex crypto function and protected custom setting to generate and subsequently store secure data.
• Get an idea of work-arounds for popular problems. For instance, Salesforce does not allow storing secure data in an Apex class, thereby preventing hard-coding secure data or putting it in a post-install script to place it in a protected custom setting. This poses problems in storing secret keys. The simple solution is to store the secret as the default value for your protected custom setting.
Using ESAPI (The OWASP Enterprise Security API), a free, open source, web application security control library would help in a big way. Programmers can leverage the ESAPI libraries to either build a solid base for new development or retrofit security into existing applications. The Force.com implementation of the ESAPI library is designed and customized for the security needs of the Force.com platform.

2. Do self testing

It is a good idea for the developer to test the app themselves before submitting it for review. If the self-test is done the right way, the app would most likely pass the security review in the first round itself, saving the developer considerable time and hassle. Retests create significant delay for the app and the process as a whole.
The Open Web Application Security projects list the following top 10 vulnerabilities detected by Salesforce in the reviews, causing submissions to fail the test:
1. SQL and XML Injection
2. Cross Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross Site Request Forgery (CSRF/XSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection (no SSL enforcement, weak or null ciphers, session cookies without secure attribute
10. Unvalidated Redirects and Forwards

The other security and integrity aspects issues that force.com takes seriously are:

• Secure Communications and Cookies
• Storing Secrets
• Arbitrary Redirects
• Access Control
• Enforcing CRUD and FLS (Force.com)
• SSO for Composite Apps

Make sure to test for such issues and other issues in the self-test phase to avoid unwanted embarrassment and delays.Developers would also do well to execute two security scanners every few weeks during the development process, to pre-empt common security clinks that Salesforce usually unearths:

• Force.com Security Source Scanner : This scanner scans Apex/Visualforce code on various critical security and code quality issues. It runs async and gives you PDF report having issue details and solutions too.
• Web Application Security Scanner : This offers an easy way to simulate variety of security attacks like SOQL Injection etc. A free license is available for ISV Partners: http://security.force.com/webappscanner

3. Take care of the non essentials

Salesforce security review is not just about unearthing security vulnerabilities. Due consideration is given to the overall quality of the code, and as such, it is important to pay attention to non-essentials, which may not be mandatory but would nevertheless place the app in good standing.
Here, the questionnaire part of the review becomes important. Once the developer submits the application for security review, Salesforce seeks confirmation from the developer on a series of issues, such as

• Whether trigger logic supports trigger
• Class and triggers do not reference any hardcore ids
• Test Bulk Logic Support
• Creating 100 test records in xls or csv
• Running data loader for each individual trigger type( insert, update, delete)
• Successfully applying validating logic to all records                                                                                         Compliance with many of such items are not mandatory, but compliance it is still a good move from the quality stand point

4. Provide Everything

The review takes place only when the submission is complete in all aspect. Apart from making sure to submit the version that is actually proposed to be put on the app exchange, make sure to include complete and accurate documentation with all necessary information filled in. Also make sure that the test environment is fully configured and complete. It is important to meet all requirements and remain within the agreement guidelines.

The field is not stacked against small players though. Although the test demands formal and detailed documentation, Salesforce understands that depending on the size and maturity of the company, this may not be practically possible for everyone. For instance, a smaller company may get away with an informal checklist instead of a formal documentation of the security policies.

What the security review team does is test all parts of the offering, including external web applications or services, client/mobile applications and all Apex and Visualforce, packaged or unpackaged, included in the offering, regardless of whether they are required or optional. The review team will exclude parts of the offering that they determine are not in scope, but when in doubt, developers are better off including it anyhow. If the review team decides that the component in question is in scope, and if it is not included, the review will be delayed.

The review process takes about 6-8 weeks from when everything provided.

5. Fix Issues

There are three possible outcomes of the review.

• Approved: The developer can then list the app in the AppExchange immediately
• Provisionally Approved: The review team identifies low or medium risk issues that do not pose any significant risk to Salesforce or the users, and offers a time-limit to remediate such issues. The developer can usually address these low-risk vulnerabilities issues easily, and in the meantime, can go ahead and create a public listing for the application on the AppExchange. However, failure to remedy the noted issues within the specified time period will result in removal of the application from the AppExchange.
• Not Approved: This worst-case scenario comes when the review team identifies high risk issues. The developer would have to address all such issues and submit the app for review, to publish in the AppExchange.
Unless otherwise noted on the test reports, the developer will have to fix all classes of issues highlighted by the review team, across the entire app. Issues marked as informational by the reviewer may be safely ignored in most cases though.

The important point to note is that the review process is a moving target. As web technologies get inflicted with new vulnerabilities, the standards also keep on changing by the day. As such, benchmarking against a previously approved app may not be enough to pass the review, and a “Not approved” status need not spell doom for the project. What matters is the ability of the developer to equip the app to ward off the latest threats.

Finally, it is pertinent to note that the Salesforce security report is not a comprehensive list of vulnerabilities in the application. Similar and additional vulnerabilities may exist outside of the review report.