If you work in a regulated industry like banking or even if you don’t, understanding the risk that your IT systems pose is an important one. If Salesforce is implemented correctly I believe it can pose less of a risk in some areas than traditional applications. But AppExchange apps could expose your precious data to other parts of the internet. So … how do you know? What checks can you make to make sure the app is “secure”?

Salesforce Security Review… or not as the case may be…

Firstly how are you installing the AppExchange app? Are you installing it directly off AppExchange or did the partner provide you with the link to install the app? When you hit the “Get it Now” button on AppExchange does the app install into your org or do you get a little message saying that you need to contact the partner first who can help you install the app?

Learn more on the Security Review Trailhead Module

So why is this important?

It’s important to know because if you are installing the app directly from AppExchange, with no third party intervention and no-one telling you “Oh no use this link instead to install the app”, you know that the app has previously passed the rigorous Salesforce Security Review and has been regularly reviewed ever since it was first uploaded. It’s similar to the security review that Apple iPhone and Android apps go through although but the Salesforce review is more rigorous. Check out the Security Review Trailhead module for more information.

I’ve been reviewing one app for a client and even though I know the AppExchange partner has a ton of developers working on the application, the last time they uploaded the app to AppExchange was in 2009! Does this mean they have been dodging the security review for nearly 10 years? Hmm… Well… yes, it does.

So what does this actually mean? Well, it could be that the application legitimately hasn’t changed since 2009. If so hitting the get it now button will allow you to install the application. Or, it may be that the application is actually more of a hybrid application. Hybrid applications actually have a very lightweight implementation in Salesforce and the actual application is hosted somewhere else on the internet. Salesforce Pardot application is a good example of this. The Pardot system isn’t part of the core Salesforce platform but they have a couple of lightweight Pardot components that you can install in your Salesforce org to visualise Pardot data in Salesforce.

Another reason for why a partner may need to install the application themselves is because it’s actually an “accelerator app”. An application which is just a collection features which allow you to accelerate the development of your system but require more development to work before they are usable.

AppExchange Unauthorised App

What to watch out for?

When you install an app watch out for the following message:

You’re installing a Non-Standard Application that is not authorised for distribution as part of the Salesforce’s AppExchange Partner Program.

You then have to accept this before you can continue to install the application. In my opinion, this should be clearer and actually say that the application has not been part of the Salesforce security review and therefore you are accepting the risk. Because really, what does a “non-standard application” that is “not authorised for distribution” actually mean?! But hey!

Although this may sound quite bad and you may think you don’t want to trust ANY applications that are not on the AppExchange it’s actually only one of a number of things that I think about when reviewing the risk of an App…

Picture Note: You may have seen this is a screenshot of the Salesforce Pardot app upgrade. Pardot, not an authorised app? Well, it is, it was just a bug with the install at the time they introduced this warning 🙂 all fixed now.

Off-Platform access?

My Salesforce Remote Site Settings

One of the GREAT things about Salesforce is that you have to “whitelist” any site on the internet that you want your Salesforce org to connect too. This goes the same for AppExchange apps as well! You can see what sites your org can connect to by going to Setup > Security > Remove Site Settings. As you can see from the screenshot from one of my developer orgs it can connect to a number of different hosts on the internet. You can see which host is related to an AppExchange package you have installed by the little blue arrow and envelope icon next to the Remote Site Name.

Now if I had an application that had been bypassed the security review or the app partner wanted me to install the app via a different link, but I noticed it had no remote sites setup, I would consider this generally quite secure. The reason being that even if there is something dodgy within the app it’s nearly impossible for that App to expose the org’s data on the internet as it doesn’t have a route out onto the wider internet except via the existing Remote Sites. Although this doesn’t completely stop data being transferred outside of the org it reduces the risk significantly.

Also, take a look at the remote sites URL. I installed a Companies House application from AppExchange which allows you to search any companies registered with UK government’s companies house database. Looking at the app it was only creating one remote site to https://api.companieshouse.gov.uk, so the developers who wrote the app still have no access to the data and the only data is being sent to a government website over SSL (https), I’m happy with that!

Is your org secure in the first place?

Salesforce does have a very flexible security model and some settings could expose your org to risk. I’m not going to go into too much depth here, but one thing to review is your Salesforce session settings. In here there are a number of settings that help secure your org from rogue applications:

• Lock sessions to the IP address from which they originated; It’s good to have this enabled as it will help stop people stealing your users session’s and reusing the session to log into your org. Many Salesforce Browser plugins rely on being able to access the users session id so that they can use the session to pull data out of the org, but what’s stopping them sending the session to someone else on the internet to use? Enabling this means that unless the hacker is using the session id from the same IP address as the user, the session id becomes useless.
• Freeze JavaScript Prototypes; This allows better code separation between lightning component authors. Again reducing the risk of passing data
• Enable XSS protection; XSS is whats called cross-site-scripting. This is where a software developer injects code into your legitimate code to do something damaging. Enabling this helps prevent this. You can read more about XSS here. Again legitimate Salesforce browser plugins actually do this to inject code into the Salesforce website to help you.
• and many more…

One thing you can do is run the Salesforce Health Check. This reviews your current basic Salesforce security and gives you a score out of 100. You can then make changes as you see fit. Search for “Health Check” in setup.

Summary

Just because you are installing a Salesforce app and Salesforce prides itself on trust and Security doesn’t mean that the app isn’t going to expose your org to risk. So make sure you check:

• You are installing the App directly from AppExchange not via a link you have been emailed/clicked on via another source unless you trust the company.
• If the app is not being installed directly off AppExchange, check and see if it needs to open up any Remote Sites and what those remote sites are.
• You have checked that you have enabled Salesforce security, particularly around session management.