Salesforce Hardens Connected Apps Security Amid Social Engineering Attacks

Salesforce is tightening security around the use of connected apps amid a wave of social engineering attacks which have seen victims download a malicious replica of Data Loader. 

The likes of Adidas, Chanel, Google, and Workday are reported to be among those targeted in the campaign – which is believed to have been orchestrated by the well-known hacker group ShinyHunters. 

Many of those affected do not directly name Salesforce when revealing the incidents, but use phrases like “third-party CRM”, with subsequent reports sometimes confirming that they are Salesforce-related. 

Salesforce recently released an advisory statement, outlining that its own platform had not been compromised and would continue to support their customers’ security posture.

Now, in a blog post titled ‘Prepare for Connected App Usage Restrictions Change’, published on August 18, the cloud giant revealed it would be restricting the use of “uninstalled connected apps”, blocking end users from using them. 

Note from SF Ben: The potential for compromised connected apps in Salesforce orgs is ongoing. We at Salesforce Ben strongly recommend that all admins and org owners should prioritize auditing the connected apps currently in use in their orgs. This includes identifying the origin of all connected apps, removing any unused or unknown apps, setting permissions for access to remaining apps, and removing the ability for any user to add connected apps without approval. We have published this article to help.

The Mothership Strikes Back

In a release which is said to arrive in early September, Salesforce will be enacting restrictions on what it refers to as “uninstalled” connected apps. These are connected apps which have been authorized by a Salesforce user, but had never been installed in the Salesforce org as a configuration. Uninstalled connected apps have always existed to support integrations that may be created by a customer or consulting partner, but never officially registered as part of the AppExchange. 

This appears to be a direct countermeasure against the social engineering attackers’ tactic of targeting English-speaking Salesforce customers with voice phishing phone calls to get them to download a hacker-controlled replica of the Data Loader app, which compromises their data. 

The update will mitigate the problems by disabling non-admin users from authorizing uninstalled new connected apps. This will close a decent amount of the surface area for orgs which have not already enacted security controls around connected apps. It will also immediately shut down any uninstalled apps authorized by the OAuth 2.0 device flow authorization process – which has known security vulnerabilities which can be more easily exploited than other OAuth flows. Finally, it introduces new user permissions intended to give admins more control over connected apps. 

Salesforce’s FAQ says: “Specific user permissions (“Approve Uninstalled Connected Apps” and “Use Any API Client”) are now required to use uninstalled connected apps. 

“Salesforce recommends using care when assigning these permissions as it allows users to bypass the restriction on using uninstalled connected apps. 

“For example, you might only give these permissions to users, such as an admin or developer, who manage connected apps and need to test the apps before installing them on the org for access of other end users.”

How Will the New Measures Affect My Org? 

Salesforce says that, to minimize disruption to existing app usage, end users can keep using uninstalled apps – if both of the following criteria apply:

• The user has previously authorized the app.
• The app is not using the OAuth 2.0 device flow.

A new user trying to access the same uninstalled apps will be blocked, Salesforce says. 

All uninstalled apps which use the OAuth 2.0 device flow will be blocked, even for specific users who have previously authorized the app. 

Connected apps installed before the change will continue to function without interruption.

Once the changes take place, only “highly trusted users with certain permissions” can use uninstalled connected apps, the CRM giant has said. 

The required permissions depend on whether API Access Control is enabled. If API Access Control is enabled, only the “Use Any API Client permission” gives access to use uninstalled apps. If API Access Control is not enabled, trusted users can use uninstalled apps if they have either one of these permissions:

• “Approve Uninstalled Connected Apps”: This new permission, added in Summer ’25, lets trusted users self-authorize and use uninstalled connected apps.
• “Use Any API Client”: This user permission lets users access Salesforce via any API client, including uninstalled connected apps and blocked connected apps.

Salesforce stresses the importance of taking care when assigning these permissions because they let users bypass the restriction on using uninstalled connected apps. 

The company said in an update: “Take steps to review and install connected apps that you want to make accessible for end-users. Block any apps that you do not trust.”

More Technical Details About the Changes

An uninstalled connected app is a configuration that exists somewhere in a Salesforce org. These are often used for integrations or client applications that are not officially part of AppExchange, such as customer apps or apps used by consulting partners. But critically, they never appear in the Connected Apps OAuth Usage part of Setup with an Install button next to them. 

Once installed, it allows the administrator to set security and access policies for the app. This is critical to ensure only the right users can access the app’s features. Previously, any uninstalled connected apps can potentially be accessed by any user until the update occurs in September. Once enacted, new users will be default locked out of accessing uninstalled connected apps. 

The other restriction has to do with any connected app which was authorized using the OAuth 2.0 device flow. In the September update, users who have previously authorized connected apps will still be able to access them, except if they were authorized using the device flow.  This may seem odd, but the device flow has a known vulnerability which is even documented in its standard, RFC8628.

This authorization flow is designed for devices with minimal UI capabilities to initiate an OAuth connection. Because of this, the authorization flow can be initiated with only a client_id making it very exploitable by a malicious actor. Even worse, if the client_id of a known app becomes known to a malicious actor, it can make the exploit even more convincing.  

Final Thoughts 

The list of big businesses affected by the campaign is expanding by the week. HR giant Workday is the most recent to reveal it was targeted in a social engineering campaign which saw threat actors gain access to information from a “third-party CRM platform”.

Salesforce has made clear that their own platform is not the issue, but nonetheless it is their customers who are being targeted in these attacks, so it makes sense they are taking measures to protect them. 

These mitigations are welcome. But this doesn’t change any of the exposure to phishing or social engineering. Should an admin – or any user with necessary permissions – be convinced by an external actor to enter their credentials and authorize a connected application, the fundamental risk is no different, so admins and org owners should be trained to look for these attacks going forward.