A Salesforce Admin’s Guide to Auditing Connected Apps

In the wake of recent social engineering attacks, it’s crucial that Salesforce Admins everywhere review their Connected Apps.

The list of Salesforce customers who have been caught out by hackers using Connected Apps to exploit customer data continues to grow. Now is the time for a thorough audit to make sure your data hasn’t been breached. 

What Is a Connected App?

A Connected App is a mechanism that allows you to access Salesforce APIs. They can be provided by Salesforce directly, locally created, or made available via the AppExchange. By default, any ‘API Enabled’ user is allowed to grant access to a Connected App.

The Salesforce Mobile App and Data Loader use a Connected App, and other third-party tools, such as Gearset, use Connected Apps too.

It’s been discovered that Salesforce users have been tricked into connecting to a fake version of Data Loader, which exposes data to hackers rather than the genuine application.

If data is breached, it can lead to legal ramifications and fines depending on your geography, not to mention reputational damage. Although we won’t explore these repercussions, it should be enough to convince your leaders to prioritize an audit of your Connected Apps, to make sure you have not been impacted. 

Step 0: Understand the Key Concepts

Each Connected App has App Policies that you can manage. These allow you to define permitted users, session timeout, and high assurance preferences. 

Permitted Users can be set as ‘all users’ or ‘admin approved users’, with the latter being the most restrictive option. For other users, grant access via Permission Sets (or Profiles). This option is only available for installed applications. 

Against an installed application, set a session timeout to control when users need to re-authenticate. If this isn’t set, the system will use the value at the user’s profile level. If the profile doesn’t have a value, then the system uses the org default. 

For an installed Connected App, you can set it to require MFA by setting the high assurance session required to true. If you enable this and then set it to ‘blocked’, no user will be able to access the app. If you set this to ‘switch to high assurance’, then users will need to verify their identity before they can access the app. Make sure you test this once enabled, as it’s only supported for Connected Apps that use a certain type of authentication. 

If a Connected App is installed, then an Admin has explicitly added it to the org, perhaps in order to adjust the app policies. 

When a Connected App is blocked, this will disconnect all active sessions and prevent users from accessing the app until it is unblocked. 

A user-authorized Connected app is something that a user has granted access to that hasn’t explicitly been installed by an admin.

A Local Connected App is an item that has been created within a specific Salesforce Org; this could be for a specific in-house system to connect to Salesforce. 

Step 1: Review Your Connected Apps

From Salesforce Setup, you can get a good idea of what Connected Apps are in use, by whom, and take action. You can use either Connected Apps OAuth usage in the Setup menu or SOQL to pull together a list of what Connected Applications exist in your organization. 

Once you’ve created a list of items, you’ll have a sense of what is installed and what’s in use. 

Step 2: Review Connected Apps 

Use the list from the previous step to make sure things are in order. If a connected app is installed, you’ll see Manage App Policies. From this screen, you can adjust permitted users, set a session timeout, and force the app to use a high assurance session before it can be accessed. 

If an app is not installed, you can block it or install it to have more granular control as to who is or isn’t allowed access. 

The following steps are based on a standard configuration. If your Salesforce org includes customizations, these steps may not provide complete coverage or protection. Always review and adapt guidance to your organization’s unique setup before making changes and ensuring you are fully protected. If you choose to block an app, this could impact users – so think twice about taking that action!

Firstly, start by reviewing the Connected Apps. Are they familiar to you or your users? If not, block them by using that action next to each item in the list. 

Once you’ve filtered out Connected Apps you do not recognize from the remaining list, you’ll need to determine what’s genuine. Connected Apps supplied by Salesforce can be found with a blue arrow next to the name under ‘Manage Connected Apps’ in Setup. 

They are automatically installed and usually have a namespace of sf_com_apps or sf_chttr_apps. As namespaces are unique, you can trust that these items come from Salesforce. If you can not verify the source for other items, then you can block these. This disconnects sessions and stops users from accessing the app until you unblock access. 

Only keep apps connected that have been used recently. If a Connected App hasn’t been used for some time, block it. You can later unblock it should a user need access again. 

You can only adjust the settings of Connected Apps that are installed, so for the remaining items, install them to get control over Permitted Users, Session Timeouts, and more. 

If a Connected App already exists, then you will not be able to install another with the same name. This is something to investigate further, as it could suggest you have a ‘malicious’ version of the Connected App installed rather than the genuine version. 

For each installed Connected App, make sure the Permitted Users are set to ‘Admin Approved Users’ and assign access to others via Permissions Sets. This follows the principle of less privilege and ensures users will only be granted access should they have permission. 

Step 3: Enable API Access Control (Optional) 

Once you’ve reviewed Connected Apps and are left with only known genuine Connected Apps that follow the principle of less privilege, you have a decision to make. 

You can enable ‘API Access Control’ by reaching out to Salesforce Support. This provides an allowlist of Connected Apps and blocks users from accessing a Connected App outside this list. Unlike other steps, this is a proactive action and can prevent the org from using unauthorized apps in the future, as it blocks connected apps. 

Once enabled, any new connected app will be blocked, which will first have to be installed and unblocked before an admin can then assign access via Permission Sets (or Profiles). 

This feature blocks any API Access that is not via a Connected App. Export Login History and review any login via APIs, including SOAP. Before you enable this feature, switch these logins to use OAuth Flows instead, which are considered more secure. 

As always, test this feature in your sandboxes first and consider that not all installed packages are compatible with ‘API Access Control’, so regression testing is important. 

‘Use Any API Client’ permission overrides API Access Control. Only assign this for a limited time via a Permission Set with an expiry date and never grant this to Business Users. 

API Access Control could break Visualforce Pages that access APIs. If this is the case, then enable ‘Allow Visualforce Pages to access APIs’ to allow access. 

Other Options

Connected Apps have been around for a while and have been superseded by External Client Apps, which provide more security options by default. You can migrate any ‘local’ Connected App to an External Client App. The migration option, however, doesn’t stop third parties from using Connected Apps, so for full assurance, use API Access Control. 

If you have access to Security Centre or Event Monitoring, which require special licenses, you can dive further into Connected App usage.

Summary

In the wake of recent social engineering attacks, it’s crucial that admins everywhere audit their connected apps.

For full assurance once the audit is complete, go on to enable API Access Control, which will block new apps by default.

Time will tell if this causes a surge in third parties providing access via External Client Apps instead of Connected Apps, as these have a more secure posture. 

Other Resources

• Manage Access to a Connected App (Salesforce Help)
• Manage API Access (Salesforce Help)