After reports of phishing attacks that allowed attackers to compromise Salesforce orgs for companies like Air France and KLM , Salesforce has announced that they will imminently be making changes to default security settings that will prevent future issues. But these changes may also have negative effects on legitimate applications. In this PRO Tips, we'll cover what the issue was, what's changing, and what you need to do to ensure you're not negatively affected.

What happened?

A hacking group calling itself ShinyHunters claimed credit for the data thefts, which were classic phishing attacks. Attackers used social engineering to contact users with access to the Salesforce database and convinced them to perform "troubleshooting" steps. The attackers then convinced those users to authorize data extraction tools using a Salesforce function called Connected Apps.

In most cases, the attackers called users on the phone, impersonating internal IT staff. Before we get into the technical issues, it's a good time to remember that having clear internal support policies that you communicate to users is the first line of defense. For example, telling users that IT will never contact them via phone without confirming their identity in some way (e.g. via Slack or another channel of communication) can stop attacks like this.

What is a Connected App?

Connected Apps allow external systems to connect to Salesforce and use Application Programming Interfaces (APIs) to do things like load and extract data. These applications can be used for legitimate purposes, like enabling backup tools to copy record and file data, or allowing development tools to push data into a Salesforce org. They also include popular form tools like FormAssembly and data loaders like Dataloader.io and JetStream.

Connected Apps shouldn't be confused with apps from the Salesforce AppExchange. These packaged apps undergo a Salesforce security review and must be installed into your Salesforce org. While they may include Connected Apps to enable outside services to access the Salesforce org, they will be exempt from any changes that we're talking about here. Instead, we're going to be talking about Connected Apps that aren't "installed" in your org.

What is an Uninstalled Connected App?

In short, this is an app that any user has previously authorized to access your Salesforce org where an Admin has not clicked the Install link in Setup->Connected Apps OAuth Usage. If you visit this page in your Salesforce org, any Connected App you see that has an Install button will be affected by the upcoming changes.

In the screenshot below, you can see Connected Apps in a Salesforce orgs. You can tell if the app is installed based on the button that's shown–if you see an Install button, the app hasn't been installed in the org.

What is Salesforce Changing?

In "early September" Salesforce will greatly lock down the ability to authorize connections to uninstalled Connected Apps. Basically, users will no longer be able to authorize these connections by default unless you do one of two things:

1. Click the Install button next to Connected Apps that you wish to allow users to access
2. Apply a new permission called Approve Uninstalled Connected Apps via either Permission Set or Profile to your users

There is technically a third way–enabling a relatively new feature called *API Access Control* unlocks a different permission you can assign to users. We've left it out here because it's highly unlikely to be enabled in your org–doing so requires filing a case with Salesforce Support.

What should I do?

It's tempting to take the second pathway–just enabling the permission on your existing users to allow the current behavior to continue. But that defeats the purpose of the controls Salesforce is putting in place. The safer path is to instead examine your list of Connected Apps and click Install for ones that you wish to enable users to access. If there are apps you don't recognize or out would like to discontinue the use of, you can click the Block button. Doing this for all of the necessary Connected Apps before Salesforce makes changes to enable new users to authorize these apps to use their accounts.

Note that Salesforce has said in its guidance that these changes will not affect users that have already authorized a Connected App–only new users. There is one exception–apps that were authorized using the OAuth Device Flow will be retroactively disabled. If you have any apps that meet this criteria, Salesforce will send a notification email to your admins.

Are there any next steps I can take?

One advantage to installing Connected Apps is that you can then, on an app-by-app basis, decide which users should be able to access them. Want to allow everyone on your team to use a tool like Gmail or Outlook integrations? You can set that app to allow any user to self-authorize.

But some apps probably should be locked down to only specific users. For example, a data loader tool should probably be limited to only System Administrators. After installing a Connected App, you can visit Setup->Manage Connected Apps for a full list your org's apps. Clicking on an individual app brings up a summary page, which has a "Edit Policies" button at the top of the page.

Clicking that button unlocks a drop-down menu labeled *Permitted Users*. By default, this value is set to All users may self-authorize, meaning that any user in your org can authorize this app to use their account. You can change this, however, to Admin approved users are pre-authorized.

Depending on your specific security policies, there are additional controls for enforcing IP restrictions and determining the length of time that the token Salesforce issues will remain valid. We'll leave those aside for now, as they're less commonly needed–just know that they're found on this same configuration page.

When you save the Settings, you can then scroll to the bottom of the page and add Permission Sets or Profiles that are authorized to use the app. In this example, I've limited JetStream to only be accessible to System Administrators.

Depending on your specific security policies, there are additional controls for enforcing IP restrictions and determining the length of time that the token Salesforce issues will remain valid. We'll leave those aside for now, as they're less commonly needed–just know that they're found on this same configuration page.

Have questions? We're here to help!

If you have questions about this process, please feel free to sign up for Office Hours–we're happy to help you build a plan to be ready for these changes!