codescience-resource-reatured-image-generic

If you’re planning to list an app on Salesforce’s AppExchange, the most daunting hurdle is likely passing Salesforce’s Security Review. Not only do you have to know what merits a secure application, you’ve got to architect for it from the beginning and check for weaknesses throughout build. Oh, and did I mention it’s a moving target? As new vulnerabilities are exposed in web technologies, Salesforce expects for you to be prepared for them.

What does it all mean?

Now, they’ve posted some really good information on how to prepare for security review, what they’re really looking for (as of today) and how you can make your code secure. However, having successfully guided over 50 applications through the process, we’ve learned that there are some unpublished tricks that can make the difference in passing on your first attempt and hitting dead end after dead end trying to apply these guidelines to your application. In preparation for Dreamforce 2014 and as a preview to Secrets Revealed: Pass Your AppExchange Security Review, we’re kicking off an ongoing series to further explain some things we’ve learned from all those successful reviews and how they might apply to your application.


Part 1: The Secret to Storing (and distributing) Secrets

Salesforce posts how they’d like for you to store keys, secrets, passwords, and other secure data on their site here.  The three key concepts for handling and storing secure data are: custom settings, apex crypto functions, and encrypted custom fields.  Each of these have their respective strengths and drawbacks.  I would recommend a combination of apex crypto function and protected custom setting to generate and subsequently store secure data.  Ideally, Salesforce would allow you to mix in the third and store it in an encrypted field in a protected setting, but that functionality is just not there yet. I’m not here to talk about that though. You can read up on how to do each of those to your heart’s content elsewhere.  What I’d like to show you is something Salesforce doesn’t discuss, probably because they’d really prefer you not to do it.  But what if you have a business requirement to distribute secure data, such as in the form of an App Exchange ISV app?  Sound familiar?  We want to distribute a secure key, so that anyone who installs our App Exchange package, can securely access our API. Hmmm… But Salesforce says we can’t store secure data in an Apex class, so we obviously can’t just hard-code it.  That also prohibits us from putting it in a post-install script to place it snugly and securely in a protected custom setting just like Salesforce recommends. So how do we get it in there? Do we log into each org after install and manually add it? Ugh… Luckily, there are people like Abhinav Gupta fighting the good fight to get your app through Security Review.  Once again, he met complexity with simplicity.  The simple solution is to store the secret as the default value for your protected custom setting.

That was easy!

Then, in your post-install script, all you have to do is create a ‘generic’ custom setting.

global class Install implements InstallHandler {
  global void onInstall(InstallContext context) {
    if(context.previousVersion() == null) {
        upsert new NSPCE__Protected_Settings__c(
            Name = 'generic'
        );
    }
  }
}

On creation, your default will be pulled in and no one will be the wiser.  The protected custom setting is completely hidden from the target org. Easy peasy! If you’re looking for how to distribute larger volumes of non-secure data in a managed package, read Hemang’s article here. The next part in our series will be on how to run those pesky BURP scans against a Canvas application.

We can’t wait to meet you at Dreamforce.  If you haven’t already signed up for one or all of our sessions, do so here!