Salesforce Security Guide: Connected Apps and Permission Sets

The Salesforce data theft campaigns of 2025 exploited no Salesforce vulnerability: attackers used connected apps, OAuth tokens, over-permissioned users and guest access settings that the customer controlled. A Salesforce org holds customer, pipeline and support case data, and often credentials pasted into cases. This guide goes deeper than the general SaaS picture and covers the controls inside the org: profiles, permission sets and roles, privileged permissions, connected app governance, integration users, Experience Cloud guest access, sessions, Health Check and Shield monitoring. It is written for Salesforce administrators, security engineers and identity teams who need settings they can act on and the detection to prove the controls work.

Key takeaways

• Connected apps are the front door. Install the apps you trust, set Permitted Users to "Admin approved users are pre-authorized", block the rest and keep "Approve Uninstalled Connected Apps" and "Use Any API Client" to a handful of administrators.
• A few permissions carry most of the risk. API Enabled, Modify All Data, View All Data, Customize Application, Manage Connected Apps and Manage Users decide whether one tricked user can empty the org; grant them through permission sets, never profiles.
• Integration users are non-human identities. Give each integration its own user on the Salesforce Integration licence with the "Minimum Access - API Only Integrations" profile, a login IP range and an owner.
• Guest access is a data exposure path. Turn off "Allow guest users to access public APIs", set Default External Access to Private and strip the guest profile, because public Experience Cloud sites are being mass scanned through the Aura endpoint.
• Logging is a licensing decision. Without Event Monitoring you get only Login, Logout and API Total Usage event logs with one day of retention, so decide what you need to investigate a data theft before you need it.

How access works in a Salesforce org

Most Salesforce entitlement problems come from confusing the access layers. Object, field and system permissions come from profiles and permission sets; record visibility comes from org-wide defaults, the role hierarchy and sharing rules.

Salesforce's guidance after the 2025 campaigns was to layer access with permission sets and permission set groups instead of broad profile permissions, which is also what makes reviews workable.

Privileged permissions and entitlement drift

Salesforce entitlement drift is the build-up of system permissions that no longer match anyone's job, through cloned profiles, "temporary" grants for a data load, consultants who never leave and managed packages that add their own permission sets. Treat these permissions as privileged and review them on their own cycle.

Run each Salesforce access review by permission first: every user, profile and permission set holding the permissions above, including integration users, connected app run-as users and users created by managed packages, each with a named human owner. After removals, watch Setup Audit Trail for the same grants returning, which signals a broken process rather than a one-off. See the Access Reviews Guide.

Connected app governance and OAuth tokens

A connected app authenticates an external application to Salesforce over OAuth. Once authorised, the app holds an access token and usually a refresh token, which by default is valid until revoked: a long-lived credential sitting with a third party. In the Salesloft Drift breach, Google Threat Intelligence reported that UNC6395 used compromised Drift tokens from 8 August 2025 until at least 18 August 2025 to query Account, Opportunity, User and Case objects across many orgs, then searched the data for AWS access keys, passwords and Snowflake tokens. The Gainsight breach followed the same pattern.

Connected app approval

Salesforce blocked uninstalled connected apps for most users from early September 2025; users who had already authorised an app keep access unless it uses the OAuth 2.0 device flow. That closed the path UNC6040 abused, where a caller talked an employee into approving a modified Data Loader through the connected app setup page and a "connection code". Administrators can still bypass the restriction, so governance is still needed:

1. Inventory: review Setup, Connected Apps OAuth Usage for apps in use, user counts and install status.
2. Classify: install trusted apps and block the rest; blocking ends the app's active sessions immediately.
3. Record: owner, data touched, scopes and vendor security contact.
4. Least scope: Google Threat Intelligence advised avoiding overly permissive scopes like full.
5. Re-approve: at least annually, and when the vendor changes ownership, has an incident or stops being used.

Connected app OAuth policies

For consent phishing and vendor offboarding across all platforms, see the SaaS and OAuth App Governance Guide.

Where identity fits: integration users and NHI sprawl

Salesforce NHI sprawl is the growth of integration users, connected app tokens, named credentials and run-as users that nobody owns. When an integration's token is stolen, the attacker acts with that integration user's permissions, so those permissions decide the size of the breach.

• Use the integration licence: the Salesforce Integration user licence (five at no extra cost in Enterprise, Unlimited and Performance editions) comes with the "Minimum Access - API Only Integrations" profile and the "Salesforce API Integration" permission set licence. API Only users reach Salesforce only through the REST, SOAP or Bulk API.
• One user per integration: Salesforce's admin guidance says sharing a user across integrations widens access and increases impact if one is compromised, and that most integrations work without System Administrator.
• Restrict by network: set login IP ranges on the integration profile to the provider's published ranges, so a token replayed from elsewhere fails.
• Owner and retirement: record the business owner, vendor, connected app and data in scope, and remove the user when the integration ends. The Klue OAuth breach involved a forgotten integration credential.
• Keep secrets out of records: UNC6395 searched case data for keys and passwords, so scan Case, Task and custom text fields and rotate anything found. See the Service Account Security Guide.

Experience Cloud guest users and the Aura endpoint

Experience Cloud (formerly Salesforce Communities) sites admit unauthenticated visitors through one shared guest user, so any object permission on its profile is granted to the whole internet. In March 2026 Salesforce warned of a campaign mass scanning public sites through the /s/sfsites/aura endpoint with a modified open-source scanning tool, harvesting names and phone numbers for follow-on vishing. Salesforce said the issue was "not due to any vulnerability inherent to our platform" but a customer-configured guest user setting.

Field-level security on Contact, Case and custom objects readable by guests needs a manual review, as Salesforce notes there is no automated check. Monitor Aura request logs for queries against non-public objects, bursts from unfamiliar addresses and off-hours access, and use GuestUserAnomalyEvent where licensed.

Authentication, sessions and Health Check

• MFA and SSO: Salesforce requires MFA for direct logins. Where users sign in through an identity provider, enforce phishing-resistant MFA there, as the FBI recommended in its September 2025 FLASH on UNC6040 and UNC6395. See the Phishing-Resistant MFA Guide.
• Login IP ranges: profile login IP ranges deny logins from outside the range, which is stronger than org-level trusted IP ranges, which only skip the identity verification challenge. Use them for administrators and integration users at minimum.
• Session settings: shorten the session timeout and lock sessions to the IP address from which they originated where the network allows, so a stolen session has a short, fixed life.
• Health Check: scores the org's settings against the Salesforce Baseline Standard and groups failures as high, medium or low risk, or informational. The Tooling API exposes the score and risks through the SecurityHealthCheck and SecurityHealthCheckRisks objects, so you can collect them from many orgs on a schedule and alert on regressions, or import a stricter custom baseline.
• Call centre and help desk staff: UNC6040 phoned call centre staff posing as IT support. Train staff that support will never ask them to authorise an app or read out a code, and give them a fast way to report the call. See the Vishing and Smishing Guide.

Event Monitoring, Shield and data export monitoring

Every org has Login History and Setup Audit Trail, which keeps the last 180 days of configuration changes. Enterprise, Unlimited and Performance editions also get a few free event log files with one day of retention. Salesforce Shield, or the Event Monitoring add-on, adds at least 50 event types, hourly delivery, longer retention, Transaction Security Policies and Real-Time Event Monitoring; Shield also covers encryption management and historical field retention.

• Salesforce API abuse: a user or connected app whose API volume jumps far above baseline, or that queries objects it has never touched, especially Case, Contact, Account and User.
• Unexpected clients: new connected apps in Login History, logins from VPN or Tor exit addresses, and new user agents for an integration user.
• Privilege changes: Setup Audit Trail entries granting Modify All Data, View All Data, API Enabled or connected app permissions, or editing OAuth policies.
• Exports: report exports from users who rarely export, and bulk jobs outside business hours. See the Data Exfiltration Guide.

Sandboxes copy production data into environments with more developers and weaker controls. Salesforce Data Mask, a managed package installed in production and run from full or partial sandboxes, replaces sensitive values with random characters or library values or deletes them, irreversibly. Mask on every refresh and treat any unmasked full sandbox as production.

Implementing Salesforce hardening

1. Baseline (weeks 1 to 2): run Health Check, export Connected Apps OAuth Usage, list holders of every privileged permission and every integration user, and forward Login History, Setup Audit Trail and the free event logs daily.
2. Quick wins (weeks 2 to 4): disable guest public API access, set Default External Access to Private, restrict the two uninstalled-app permissions and move API Enabled from profiles to a permission set. Test guest changes on a staging site first, because pages that relied on broad access will break.
3. Connected apps (weeks 3 to 8): switch trusted apps to admin approved, enforce IP restrictions and set a refresh token policy. Pilot on low-risk apps and confirm the vendor can re-authorise before blocking untrusted apps. Roll back by reverting the policy, not uninstalling, so you do not revoke every user's token by accident.
4. Integration users (weeks 4 to 12): migrate shared or administrator-level integrations to dedicated Integration licence users in a sandbox, starting minimal and adding only what tests require, then cut over and monitor for about a month as Salesforce advises.
5. Detection (from month 2): run Transaction Security Policies in alert-only mode for two to four weeks, tune thresholds, then block the clearest cases such as very large report exports.

Decision guidance

• Admin approved or self-authorise: admin approved suits any app touching customer data; self-authorise is acceptable only for low-risk, read-limited apps.
• Shield or base logging: an org with regulated data, high-volume customer records or public sites needs Event Monitoring to answer "what did they take"; a small org can start with daily collection of the free logs and accept a reliance on Salesforce support for deeper investigation.
• Profile IP ranges or identity provider conditions: profile ranges are absolute and suit administrators and integration users; a mobile workforce is better served by device and location conditions in the identity provider.
• Small or large estate: a small org can review permission sets by hand each quarter; a multi-org estate needs the Tooling API to collect Health Check and permission data centrally.

Metrics

• Health Check score per org and the count of high-risk settings.
• Uninstalled or self-authorised connected apps touching customer data, trending to zero.
• Holders of API Enabled, Modify All Data or View All Data as a share of active users.
• Integration users with an owner, dedicated licence and login IP ranges, as a percentage of all integration users.
• Days of event log retention available to investigators, against your incident scoping target.

Framework mapping

In NIST CSF 2.0 these sit mainly in PR.AA, PR.PS, DE.CM and, for connected app vendors, GV.SC.

Common failure patterns

• Treating the 2025 incidents as Salesforce vulnerabilities: Google Threat Intelligence found UNC6040 relied on "manipulating end users, not exploiting any vulnerability inherent to Salesforce", so waiting for a patch fixed nothing. See the ShinyHunters Salesforce data theft campaign.
• Integration users with System Administrator: one stolen token then reads every object, as the Drift and Gainsight thefts showed at scale.
• Refresh tokens left valid until revoked for years: they outlive the project, the contract and the people who approved them.
• Guest profiles granted object access "to make the page work": the permission applies to every anonymous visitor and to Aura queries, not just the page.
• Free logs never collected: with one-day retention, an incident found on Monday has already lost the weekend's API activity.
• AI agents acting on inbound records: agents processing public form submissions inherit the agent user's access; see ForcedLeak.

Practitioner checklist

• Export Connected Apps OAuth Usage, install the apps you trust and block the rest.
• Set Permitted Users to admin approved, IP Relaxation to enforce and a refresh token expiry for every app touching customer data.
• Limit "Approve Uninstalled Connected Apps", "Use Any API Client", Customize Application and Manage Connected Apps to named administrators.
• Remove API Enabled, Modify All Data and View All Data from profiles and grant them only through owned permission sets.
• Move every integration to its own Integration licence user with login IP ranges and a named owner.
• Disable guest public API access, set Default External Access to Private and strip each guest profile.
• Run Health Check monthly and alert on new high-risk settings.
• Forward Login History, Setup Audit Trail and event logs daily, and decide whether you need Event Monitoring to scope a data theft.
• Scan Case and other text fields for credentials, rotate anything found and mask every sandbox on refresh.

Standards and references

• Salesforce Admins: Get Ready for Changes to Connected App Usage Restrictions
• Salesforce: Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access
• Salesforce Admins: Best Practices for Configuring Your Integration User
• Salesforce Developers: Manage OAuth Access Policies for a Connected App
• Salesforce Trailhead: Get Started with Event Monitoring
• FBI: Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Instances for Data Theft and Extortion
• Google Threat Intelligence Group: The Cost of a Call: From Voice Phishing to Data Extortion
• MITRE ATT&CK: T1213.004 Customer Relationship Management Software

Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · Data Exfiltration Guide · Service Account Security Guide · Salesloft Drift Breach