The large Salesforce data thefts of 2025 did not exploit a flaw in the platform: they used settings that let any user authorise an app, tokens that never expired and integrations that could call the API from anywhere. This list ranks the ten Salesforce misconfigurations that most often turn a phone call, a stolen integration token or a curious guest user into a bulk export of customer records. For each one it explains what the setting looks like in a real org, why attackers want it, how to check for it and how to fix it, using Salesforce's own documentation for setting names. It is written for Salesforce administrators, CRM platform owners, identity teams and the security leads who answer for customer data. For the full control set, read the Salesforce Security Guide; this page is the short list of what goes wrong most often.
This is an independent guide from NHI Mgmt Group, based on Salesforce's public documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.
The Top 10 at a glance
| # | Misconfiguration | What it enables | Where to fix it |
|---|---|---|---|
| 1 | Users can self-authorise any connected app | Vishing that ends with an attacker app inside the org | Connected app OAuth policies, API Access Control |
| 2 | Integration refresh tokens valid until revoked, IP restrictions relaxed | Stolen vendor tokens that work for years, from anywhere | Refresh Token Policy, IP Relaxation |
| 3 | Powerful permissions spread wide | One compromised user can read, export or reconfigure everything | Profiles, permission sets, permission set groups |
| 4 | API access open to every user and every client | Data Loader style bulk export by any phished account | API Enabled permission, API Access Control |
| 5 | No login IP ranges, or ranges checked only at login | Sign-ins and sessions from VPN, Tor and attacker hosts | Profile login IP ranges, Session Settings |
| 6 | Experience Cloud guest users with too much access | Unauthenticated record reads from the public site | Guest user sharing rules, guest profile |
| 7 | MFA and SSO gaps for admins and local logins | Phished passwords that still work | MFA settings, SSO and login policies |
| 8 | Weak session settings | Long-lived or hijacked browser sessions | Session Settings |
| 9 | No monitoring or blocking of bulk export | Exfiltration nobody sees until the extortion email | Event Monitoring, Transaction Security |
| 10 | Secrets stored in cases, notes and records | CRM theft becomes cloud and data platform compromise | Data governance, scanning, redaction |
The ranking is editorial: it is NHI Mgmt Group's view, weighting how often each setting appeared in 2025 and 2026 incidents we track and how much data it exposes, not a statistical survey. Items 1, 2 and 9 work together: control which apps and tokens get in, restrict where they connect from, and alert on large exports. Health Check, which compares an org against the Salesforce Baseline Standard or a custom baseline, covers parts of items 5, 7 and 8; review connected app policies, permission sprawl and secrets in records separately.
1. Users can self-authorise any connected app
The misconfiguration: connected apps keep the default Permitted Users policy, "All users may self-authorize", and the org has no allowlist of approved apps. Any user who is talked into it can authorise a new OAuth client against their own account, with their own data access.
Why it matters: voice phishing campaigns target this setting. Callers posing as IT support (MITRE ATT&CK T1566.004 Spearphishing Voice) walk support staff through entering a connection code that links a renamed copy of Data Loader to the tenant. The attackers manipulate end users rather than exploiting any Salesforce vulnerability.
How to check: in Setup, review Connected Apps OAuth Usage for every app with active tokens, who authorised it and when; list users holding "Manage Connected Apps" and "Customize Application".
How to fix: set the OAuth policy for every approved app to "Admin approved users are pre-authorized" and assign access through profiles or permission sets. Request API Access Control from Salesforce Customer Support, which Salesforce describes as blocking API access for all users unless they are pre-authorised through an approved (allowlisted) connected app. Train support teams that legitimate IT never asks for a connection code or an MFA code over the phone. See How to review Salesforce connected apps and integration users and the Vishing and Help Desk Social Engineering Awareness Guide.
2. Integration refresh tokens valid until revoked, IP restrictions relaxed
The misconfiguration: third-party integrations run with the default Refresh Token Policy, "Refresh token is valid until revoked", and IP Relaxation set to "Relax IP restrictions", so a token issued years ago still works from any network.
Why it matters: refresh tokens are non-human credentials held by someone else (T1528 Steal Application Access Token, then T1550.001 Application Access Token). Old, untracked refresh tokens and tokens held in an integration vendor's environment both let an attacker act as a trusted app (T1199 Trusted Relationship).
How to check: for each connected app, record the Refresh Token Policy, IP Relaxation value, scopes, the integration user it runs as and the business owner. Flag any third-party app on "valid until revoked" with relaxed IP restrictions.
How to fix: choose "Expire refresh token if not used for" or "Expire refresh token after" with a value the vendor can support, set IP Relaxation to "Enforce IP restrictions" and add the vendor's published egress ranges to the integration user's profile login IP ranges. Narrow OAuth scopes to what the integration uses. When a vendor reports an incident, revoke all of its tokens first and ask questions second. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide and the OAuth Token Theft Incident Playbook.
3. Powerful permissions spread wide
The misconfiguration: "Modify All Data", "View All Data", "Customize Application", "Manage Connected Apps", "Manage Users" and the ability to export reports or mass update records sit in broad profiles, or in cloned System Administrator profiles given to consultants, integration users and team leads.
Why it matters: in a vishing attack the attacker gets exactly what the victim has. Salesforce's own guidance on social engineering tells customers to review which users hold "Customize Application" together with "Modify All Data" or "Manage Connected Apps", and to limit who can mass import, update or delete records with Data Loader.
How to check: report on every user with these permissions through any profile, permission set or permission set group; count System Administrators; list integration users with administrator profiles.
How to fix: move to a minimum-access profile plus task-based permission sets and permission set groups, which Salesforce recommends over broad profile permissions. Keep "Modify All Data" and "View All Data" to a small named admin group, give each integration its own integration user with object-level access only, and review assignments quarterly. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
4. API access open to every user and every client
The misconfiguration: the "API Enabled" permission is granted to standard user profiles that only ever use the browser, and no restriction exists on which API clients may connect.
Why it matters: bulk theft from Salesforce runs through the API, not the user interface. In the 2025 campaigns attackers ran small count queries against objects such as Account, Opportunity, User and Case before bulk-exporting whole tables (T1213.004 Customer Relationship Management Software). A support agent with API access and a phone becomes a data export channel.
How to check: list profiles and permission sets granting "API Enabled" and compare them with the users who appear in API login history.
How to fix: remove "API Enabled" from interactive-only roles, keep it for integration users and named administrators, and combine it with API Access Control (item 1) so even API-enabled users can only use approved clients.
5. No login IP ranges, or ranges checked only at login
The misconfiguration: profiles have no login IP ranges, or ranges exist but "Enforce login IP ranges on every request" is off, so a session or client established elsewhere keeps working.
Why it matters: the 2025 export traffic came from commercial VPN and Tor addresses. Salesforce documents that when one or more login IP ranges exist on a profile, a login from any other address is denied, and that the every-request setting applies the ranges to each page request, including requests from client applications.
How to check: list profiles without login IP ranges, especially administrator and integration user profiles; confirm the Session Settings value.
How to fix: set ranges on administrator and integration profiles first (corporate egress and the vendor ranges from item 2), then turn on "Enforce login IP ranges on every request". Org-wide trusted IP ranges on the Network Access page reduce device verification challenges but do not block logins, so do not confuse the two. On Hyperforce, Salesforce suggests considering mTLS or allowed domains as alternatives to IP allowlists.
6. Experience Cloud guest users with too much access
The misconfiguration: guest user sharing rules expose whole objects rather than the few records a public page needs, the guest user profile carries object permissions and Apex class access left over from a build, and public pages call Aura or Apex methods that return more fields than they display.
Why it matters: anyone on the internet is the guest user. Salesforce now enforces secure guest user record access in every org with Experience Cloud sites: org-wide defaults for guests are Private and cannot be changed, guests cannot be given access through manual or Apex managed sharing, and guest user sharing rules are the only way to grant them record access, Read Only. That narrows the problem to the rules and profile permissions you create, which is where exposures now come from.
How to check: for each site, list guest user sharing rules and their criteria, the guest profile's object and field permissions and the Apex classes it can run; test the site logged out.
How to fix: write sharing rule criteria that match only the public records, remove unused object, field and Apex access from the guest profile, and run Apex used by public pages with sharing enforced. See the Salesforce Experience Cloud Security guide.
7. MFA and SSO gaps for admins and local logins
The misconfiguration: users sign in through single sign-on but can still log in directly with a Salesforce password, administrators keep local logins for emergencies with weak methods, and some accounts are excluded from MFA during a project and never put back.
Why it matters: several 2025 callers also asked victims for passwords and MFA codes, then reused them against other cloud services. Salesforce states that MFA is automatically enabled for direct logins, but an exempted account, a phishable method or a direct-login path around SSO reopens the gap.
How to check: review Login History by login type for direct logins by users who should only use SSO; list users with MFA waivers and their registered methods.
How to fix: disable direct login for SSO users where the org supports it, keep two documented break-glass administrators with phishing-resistant authenticators and alerts on their use, and remove MFA exemptions with an end date. See the Phishing-Resistant MFA Guide.
8. Weak session settings
The misconfiguration: long inactivity timeouts, "Lock sessions to the IP address from which they originated" off for administrators, and "Require HttpOnly attribute" disabled for a legacy customisation.
Why it matters: a stolen session cookie or an unattended browser bypasses MFA entirely. Salesforce describes IP-locked sessions as a guard against session hijacking and the HttpOnly attribute as blocking script access to the session ID cookie.
How to check: read Session Settings and the session settings on administrator profiles, which can override the org value.
How to fix: shorten the Timeout Value with "Force logout on session timeout", require HttpOnly, and lock sessions to the originating IP for administrator profiles where network patterns allow. Use high assurance session security for Setup access if your org supports it.
9. No monitoring or blocking of bulk export
The misconfiguration: nobody reviews API, report export or bulk API activity; Event Monitoring log files are not collected; no Transaction Security policy exists for large downloads.
Why it matters: CRM data theft usually involves large exports that run for days. Real-Time Event Monitoring can drive Transaction Security policies that block or notify on ApiEvent, BulkApiResultEventStore, ReportEvent, ListViewEvent and LoginEvent, and can notify on ApiAnomalyEventStore, ReportAnomalyEventStore, CredentialStuffingEventStore and SessionHijackingEventStore. Salesforce documents these as requiring a Shield or Event Monitoring add-on subscription.
How to check: confirm where login history, Setup Audit Trail and event logs land, how long they are kept and who receives alerts.
How to fix: stream logs to your SIEM, alert on the signals in the detection table below and add Transaction Security policies for row counts above an agreed threshold. Without the add-on, alert on Login History from unexpected addresses and on Setup Audit Trail changes to connected apps and permissions. See the Salesforce Event Monitoring Detection Guide.
10. Secrets stored in cases, notes and records
The misconfiguration: customers and engineers paste API keys, passwords and log files into support cases, case comments and email-to-case threads, and no scanning or redaction runs on them.
Why it matters: attackers search exported CRM data for cloud access keys, passwords and data platform tokens stored in records. CRM theft becomes cloud compromise (T1552 Unsecured Credentials).
How to check: run a secrets scanner over a sample export of Case, EmailMessage and attachments in a controlled environment.
How to fix: redact secrets on entry, tell customers to share credentials through a secure channel instead of a case, delete or mask historic findings, and treat every secret found as already exposed and rotate it. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.
Detection: what to alert on
| Signal | Source | Items |
|---|---|---|
| New connected app authorised by a non-admin user | Connected Apps OAuth Usage, Setup Audit Trail | 1, 4 |
| API calls from an integration user outside the vendor's ranges | Login History, ApiEvent | 2, 5 |
| Permission set or profile change granting Modify All Data, View All Data or Manage Connected Apps | Setup Audit Trail, PermissionSetEventStore | 3 |
| Count queries followed by bulk queries on Account, Contact, Opportunity, User or Case | ApiEvent, BulkApiResultEventStore | 4, 9 |
| Logins or API traffic from Tor exit nodes or commercial VPN ranges | Login History, LoginEvent | 5, 7 |
| Spikes in unauthenticated requests to public site pages | Site and CDN logs | 6 |
| Session hijacking or credential stuffing detections | SessionHijackingEventStore, CredentialStuffingEventStore | 7, 8 |
Common failure patterns
- Treating Health Check as the whole answer: a high score while connected app policies, permission sets and guest sharing rules go unreviewed.
- Revoking only the named app after a vendor incident: leaving other tokens from the same vendor and the secrets in its readable records untouched.
- Fixing users but not integrations: MFA and IP ranges for people while integration users keep administrator profiles, no ranges and immortal tokens.
- Buying monitoring and not tuning it: event logs collected but no threshold agreed for a bulk export, so the alert never fires.
- Sandboxes forgotten: full-copy sandboxes holding production data with weaker settings and broader access than production.
Lessons from incidents
The 2025 campaigns we track used three different ways in: a phone call and a self-authorised app, tokens stolen from an integration vendor's cloud environment, and long-lived tokens of unclear origin. Our recommendation is the same three controls for each: only approved apps and approved clients, integrations confined to known networks with expiring tokens, and an alert on bulk export. These are customer-side settings. The Salesforce Org Compromise Playbook covers the response steps.
Mapping to OWASP
No OWASP list covers Salesforce configuration directly; the OWASP Non-Human Identities Top 10 fits most items because the core risks are integration identities and their tokens. ATT&CK and NIST references are added for control owners.
| Item | OWASP NHI Top 10 | MITRE ATT&CK | NIST SP 800-53 / CSF 2.0 |
|---|---|---|---|
| 1. Self-authorised apps | NHI3 Vulnerable Third-Party NHI | T1566.004 | AC-3, CM-7 / PR.AA-05 |
| 2. Immortal integration tokens | NHI7 Long-Lived Secrets, NHI1 Improper Offboarding | T1528, T1550.001, T1199 | IA-5, SA-9 / GV.SC-07 |
| 3. Permission sprawl | NHI5 Overprivileged NHI | T1078.004 | AC-6, AC-6(5) / PR.AA-05 |
| 4. Open API access | NHI5 Overprivileged NHI | T1213.004 | AC-3, CM-7 |
| 5. No IP ranges | NHI4 Insecure Authentication | T1078.004 | AC-3, SC-7 |
| 6. Guest exposure | Not an NHI item (see OWASP Top 10 A01 Broken Access Control) | T1213.004 | AC-3, AC-6 |
| 7. MFA and SSO gaps | Not an NHI item | T1566.004, T1078.004 | IA-2 / PR.AA-01 |
| 8. Weak sessions | Not an NHI item | T1550.001 | AC-12, SC-23 |
| 9. No export monitoring | Not an NHI item | T1213.004 | AU-6, AU-12, SI-4 / DE.CM-03 |
| 10. Secrets in records | NHI2 Secret Leakage | T1552 | IA-5 |
Where to start
- Week one: export the list of connected apps with active OAuth tokens, their policies and owners; revoke anything without an owner (items 1 and 2).
- Week one: list every holder of Modify All Data, View All Data, Customize Application and Manage Connected Apps; remove the obvious excess (item 3).
- Weeks two to three: move approved apps to "Admin approved users are pre-authorized", set refresh token expiry and enforce IP restrictions for third-party integrations, agreeing ranges with each vendor first (items 1, 2 and 5).
- Weeks three to four: request API Access Control, remove API Enabled from interactive-only roles and test integrations in a sandbox before production (item 4).
- Month two: review guest sharing rules, MFA exemptions and session settings; switch on log streaming and bulk export alerts (items 6 to 9).
- Ongoing: scan cases for secrets, rerun Health Check weekly with score-drop notifications, and repeat the connected app review quarterly. Roll back a breaking change by restoring the previous policy on the single app or profile affected, not by relaxing the setting org-wide.
Practitioner checklist
- Every connected app has an owner, a purpose and "Admin approved users are pre-authorized".
- API Access Control enabled so only allowlisted clients can call the API.
- Third-party refresh tokens expire and IP restrictions are enforced to vendor ranges.
- Modify All Data and View All Data held only by a small named admin group.
- API Enabled removed from browser-only users.
- Login IP ranges on admin and integration profiles, enforced on every request.
- Guest user sharing rules and guest profile permissions reviewed, site tested logged out.
- No undocumented MFA exemptions; SSO users cannot bypass SSO with a password.
- Bulk export alerts or Transaction Security policies live and tested.
- Cases and comments scanned for secrets; findings rotated.
Standards and references
- Salesforce: Protect Your Salesforce Environment from Social Engineering Threats
- Salesforce Help: Manage OAuth Access Policies for a Connected App
- Salesforce Help: API Access Control
- Salesforce Help: Restrict Login IP Addresses in Profiles
- Salesforce Help: Secure Guest User Record Access
- Salesforce Help: Transaction Security Policy Types
- Salesforce Help: Health Check
- MITRE ATT&CK: Customer Relationship Management Software
Related NHI Mgmt Group resources: Salesforce Security Guide · How to review Salesforce connected apps and integration users · Salesforce Event Monitoring Detection Guide · Salesforce Org Compromise Playbook