Keep your (users) API access in check (part 1)

TL/DR: you should turn on API Access Control as soon as you can!

ORIGINAL POST:

There are tons of amazing applications out there that connect to Salesforce - heroku apps like the perm comparator, salesforce plugins for excel, chrome extensions, and on and on. These tools allow users and admins to do amazing things, and they all do them using APIs that Salesforce provides.

However, there has been, until recently, very limited abilities to control which apps a given user can access. By default, any user with the API enabled permission can use any extension or third party tool out there without any additional permissions. Period. And this permission is enabled by default for all standard profiles in a developer org, and likely is enabled for most of the profiles in your org as it is needed to access Salesforce1 and other key apps.

Its important to emphasize that these applications can only access the API within the field and object permissions of the user. That means if a user does not have read access on an object, there is no way to ‘get around’ that. However, there are some edge cases that are concerning, and a number of important reasons that admins should be concerned about allowing all users unfettered access to the API.

This post will explain why you should be concerned, and a follow-up post will explain what options exist that can allow you to exert more control and governance over API access.

So first, why should you care? Here are a few reasons:

  1. Security of the tool / extension

    While Salesforce has excellent security out of the box, and apps on the app exchange go through a robust security review process, the same can not be said for anything that is not listed as a managed package on the appexchange, ie for chrome extensions, heroku apps, etc. There is simply nothing that prevents an application from doing something unsavory with your data, once you give it access. And for folks who do business in the EU, you know that they take their data privacy rather seriously. Do your due diligence before you have a problem on your hands.

  2. Great power, no controls!

    Somewhere someone said that With great power comes great responsibility. Even assuming that your users are a well-intentioned bunch, these apps and extensions can give users a huge amount of power, regardless of their skill or ability to wield it.

    Some examples:

Please note that these are all apps I myself use and love. I am in no way maligning them. These are all great tools - for the right user and the right use case. But - malicious intent aside - they also make it much easier for things to get screwed up in no time flat. They also make it much easier to exploit holes in your organization’s (or an app’s) security. I simple do not want any user - without any additional vetting process - to have access to any tool out there, period.

I mean really - do you really want any application out there to be able to read your data? I dont, and while I may be paranoid, its always for a good reason.

So, what is an admin to do?

I will get into more details in a follow-up post, but until then, here is a summary of what I think the best option is.

~~Salesforce, as of Spring 15, has offered ‘API Client Whitelisting’. ~~

Its now called api access control

This feature can be turned on by request, and requires some preparation to avoid potentially significant disruption to your users. Once enabled and activated in your org, all API access is blocked unless its specifically authorized by a ’connected app’

The beauty of connected apps is that they allow administrators “explicit control over who can use the application”, as admins can grant access to specific connected apps to specific users, via profiles and permission sets.

Salesforce automatically provides connected apps for key tools like Workbench, Salesforce1, SalesforceA, etc. However, not all tools offer connected apps. With API Client Whitelisting enabled, Users would no longer be able to access tools that do not offer a connected app, unless you grant them the ‘use any endpoint’ permission. But at least an admin can control which users this is granted to, as opposed to granting it to all users by default, and trying to audit the apps that are accessing your instance.

In order to enable API Client Whitelisting, you need to reach out to Salesforce Support. Once its been enabled in your org, there should be no impact on users until you activate it, but definitely start in a sandbox and then take it from there.

More to come…soon…ish.

UPDATE - 04-04-2017
An amazing Spring17 new feature allows you to create Connected Apps for (almost) everything* that uses the api.

*With the notable exception of work.com skills, which does not work with API client whitelisting enabled and for which i have not figured out how to create a connected app. See this known issue
known issue is now marked as no-fix…

UPDATE SUMMER 17
summer17 appears to have broken the awesomeness. You can click ‘install’ to create the connected app but then…nothing…cant manage it or uninstall it. There is a known issue w scheduled fix winter 18 patch 2…so..for now the use any api endpoint permission is still needed for anything that doesnt provide a connected app ootb. this summer 17 bug was fixed by spring 18.

UPDATE WINTER 18
h/t to adam kramer who pointed out that there is no connected app option for developer console. only way to access is with the use any api endpoint permission - there is no way to provide granular access via a connected app. vote early, vote often

for the 13 of you who still use work.com skills (which could have been awesome), you are also out of luck, as skills does not work w/ api whitelisting, and the product managers that be marked the known issue as ‘no fix’.

UPDATE SPRING 22
For the three of you that somehow found a use for syndication feeds (RSS/Atom) on force.com sites (documentation), sadly you are also out to pasture with the work.com skills folks. Site guest users can no longer access the feeds, and you cannot grant use any api endpoint permission for them. Support says that “this issue has been identified as a bug at our end and would be fixed soon in the upcoming patches/releases” which seems unlikely but never say never

 
31
Kudos
 
31
Kudos

Now read this

Auditing Permission Sets

While permission sets makes assigning permissions a breeze, it can be a bit of a bear to audit all 150 of them. By audit, i mean see which ones give you [some permission] on [some object] So this blog post will cover a number of ways to... Continue →