Search
Twitter
« Salesforce.com Spring '11 Release Preview | Main | Cloud Computing Categories »
Thursday
Dec302010

Preparing for Salesforce Security Review (Part 2 of 2) 

Read Part 1 of Preparing for Salesforce Security Review

It's been a little while since we posted part 1 of the security review preparation article. I thought I would add a few things.

One of the things you will need to do before submitting for the scan is remove any System.debug() code that you are using for testing. I think the idea is to make sure the logs are clean and uncluttered while the review is taking place. I can't say for certain if this is okay for all cases but I will say that I had an app that I removed the debug info for, submitted it for the audit, then added the necessary debug info back before publishing. I had no issues with future audits of the same app at that point. The way it has worked is that each time I publish a new version of the package, Salesforce does an automated scan and re-approves.

Visualforce Security Tips

I highly recommend taking a look at the Security Tips for Apex and Visualforce Developers article. This is a great resource and one you should adhere to. I touched on this in the first article but I paid particular attention to SOQL injectionand Cross-Site Request Forgery (CSRF). With regards to SOQL injection, you want to make sure you go through and make sure your application respects the organization's (the one running the application) object-level (CRUD) and field-level security (FLS).  In our case, we when through and made sure we were properly using the "with sharing" keyword. Example:

public class myController {

     public void read()  {

           Lead lead = [Select FirstName, LastName, Email where Id = :value];

    }

}

In this case, all lead records will be searched even when the logged in user would not normally have permission to view all the lead records.

You want to make sure you use the qualifying keywords "with sharing" when declaring the class:

public with sharing class myController {

...

}

What this does is directs the Salesforce platform to use the security sharing permissions for the user that is currently logged in. So, if they can normally only see 50 out of a total of 250 of the leads in the system - those 50 are all they will have access to here. It's pretty slick from a developer standpoint. For more information on with sharing in Apex take a look here.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (4)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.