Skip to content
SteveTechArcSteveTechArc Courses

The Three Doors

Module 3 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. Each module stands on its own. Previous: Protecting What Crosses · Next: One Integration, One Identity

The question this module answers: How did attackers actually reach Salesforce data in 2024 to 2026, and what does that change about the integrations you design?

The Platform Held. The Doors Didn’t.

Section titled “The Platform Held. The Doors Didn’t.”

Between 2024 and 2026, data was taken from a lot of Salesforce orgs. You probably saw the headlines. And here’s the part the headlines often missed: in every case, Salesforce and the outside investigators say the platform itself wasn’t broken into. Nobody broke the encryption from chapter 12. Nobody found a flaw in the APIs.

They came through doors. Doors that were part of how the orgs were set up, and how the integrations were trusted.

Salesforce put the principle in one line: “Cybersecurity is a shared responsibility between a provider and their customers” (Protect Your Salesforce Environment from Social Engineering Threats (opens in a new tab), Salesforce, March 12, 2025, checked 2026-11-07). Both halves of that sentence are true, and I want this module to be fair to both. The platform gave customers the controls. Many weren’t turned on. And Salesforce has since been turning more of them on by default.

I sort what happened into three doors.

The Person Door

Section titled “The Person Door”

Someone is talked into it. In 2024 and 2025, callers posing as IT support phoned employees and walked them through approving an app. The app was usually a modified copy of Data Loader under another name. Google’s threat researchers: the caller “guides the victim to visit Salesforce’s connected app setup page to approve a version of the Data Loader app with a name or branding that differs from the legitimate version,” or to “enter a ‘connection code,’” which is the OAuth device flow. Once approved, the app exported data through the API. Google’s verdict: “In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce” (The Cost of a Call: From Voice Phishing to Data Extortion (opens in a new tab), Google Threat Intelligence, June 4, 2025, checked 2026-11-07).

What closes it. Ordinary users can no longer approve an app the org hasn’t installed: from September 2, 2025, Salesforce “blocks end users from using uninstalled connected apps,” to “Prevent users from sharing Salesforce data with unfamiliar third parties” (Prepare for Connected App Usage Restriction (opens in a new tab), Salesforce Help, checked 2026-11-07). And from November 30, 2026, the device flow only works for local External Client Apps, because it “is intended only for apps that run on devices with limited input or display capabilities,” like smart TVs (Restrict the OAuth 2.0 Device Flow to Local External Client Apps (opens in a new tab), Salesforce Help, checked 2026-11-07). Add to that: only the people who need it get API access (module 4), and someone owns the list of approved apps (module 6).

The Partner Door

Section titled “The Partner Door”

A trusted app’s stored token. In August 2025, an attacker who had broken into a sales-chat vendor’s systems used the OAuth tokens that vendor’s integration held for its customers’ orgs. The tokens were valid, so the API calls looked like the integration’s own. Google: “The actor systematically exported large volumes of data from numerous corporate Salesforce instances,” then searched what it took for secrets people had typed into records: “AWS access keys (AKIA), passwords, and Snowflake-related access tokens.” On August 20, 2025, the vendor and Salesforce revoked every token the integration held, and Google says: “This issue does not stem from a vulnerability within the core Salesforce platform” (Widespread Data Theft Targets Salesforce Instances via Salesloft Drift (opens in a new tab), Google Threat Intelligence, August 26, 2025, updated August 28, checked 2026-11-07). Google’s update two days later widened it: the scope “is not exclusive to the Salesforce integration.”

What closes it. You can’t secure your partner’s servers. You can limit what their token can do and how long it lives: narrow scopes, not full access; the app locked to the partner’s IP addresses where it can be; refresh token rotation, so a copied token stops working, as module 1 showed; and, where both sides support it, DPoP, so a stolen token is useless on another machine. Module 7 takes those apart. And notice what made it worse: secrets stored in ordinary records. That’s module 8.

The Public Door

Section titled “The Public Door”

No login at all. In March 2026, Salesforce warned of a campaign scanning public Experience Cloud sites. Every public site has a guest user, the identity of anyone who visits without logging in. Where a site’s guest access had been set wider than intended, the scanner could read records through the site’s APIs without signing in. Salesforce: “malicious actors are exploiting customers’ overly permissive Experience Cloud guest user configurations,” and “this activity relates to a customer-configured guest user setting, not a platform security flaw.” And: “Salesforce remains secure, and this issue is not due to any vulnerability inherent to our platform” (Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access (opens in a new tab), Salesforce, March 7, 2026, updated March 11, checked 2026-11-07).

What closes it. Salesforce’s post lists ten actions, starting with auditing what the guest profile can see and turning off guest access to the public APIs where it isn’t needed. The guest user belongs mostly to the Sharing and Visibility course. For an integration architect, the lesson is narrower and sharper: this door is an API that answers without any OAuth at all. If you built something for a public site, an Apex REST endpoint or a webhook receiver, the guest user is its caller (chapter 8), and the guest user’s access is its security.

Three Doors, One Picture

Section titled “Three Doors, One Picture”
The three doors The three doors: three panels. The person door, someone is talked into it: a caller posing as IT support; an employee approves the caller's app; the app exports data through the API; closed by approving only known apps and a restricted device flow. The partner door, a trusted app's stored token: a vendor's systems are broken into; its stored tokens for many orgs are taken; the tokens are valid, so the calls look normal; closed by refresh token rotation, narrow scopes and IP limits. The public door, no login at all: a public site's guest user; guest access set wider than intended; records read without signing in; closed by secure guest settings and Salesforce's ten actions. Underneath: in every case, Salesforce and outside investigators say the platform wasn't broken into; the doors were left open. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} The person door someone is talked into it A caller posing as IT support. An employee approves the caller's app. The app exports data through the API. Closed by: approved apps only; a restricted device flow. The partner door a trusted app's stored token A vendor's systems are broken into. Its stored tokens for many orgs are taken. The tokens are valid, so the calls look normal. Closed by: refresh token rotation; narrow scopes; IP limits. The public door no login at all A public site's guest user. Guest access set wider than intended. Records read without signing in. Closed by: secure guest settings; Salesforce's ten actions. In every case, Salesforce and outside investigators say the platform wasn't broken into. The doors were left open. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

A person persuaded, a partner’s token, a public site with too much open.

Three different ways in, and one thing in common: each depended on something an org had allowed. An app anyone could approve. A token that could do too much, for too long. A guest that could see too much. That’s good news for an architect. Allowing is a design decision, and design decisions can be changed.

The Same Room at the End

Section titled “The Same Room at the End”
Every door ends in a normal-looking call Every door ends in a normal-looking call. On the left, three doors: the person door, an app someone was talked into approving; the partner door, a vendor's stored token; the public door, a guest user with no login. Each leads, by the app's token, the stolen token or guest access, to the same place, highlighted: an API call that looks legitimate, made with a real token or real guest access. That call reads your data, queried and exported, often in bulk. The legend: where they meet, so close the doors and watch the calls. Underneath: nothing here looks like a break-in; watching for the unusual call is chapter 14. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} The person door an app someone was talked into approving The partner door a vendor's stored token The public door a guest user, no login An API call that looks legitimate a real token, or real guest access Your data queried and exported, often in bulk the app's token the stolen token guest access reads Nothing here looks like a break-in. Watching for the unusual call is chapter 14. HOW TO READ IT Where they meet: so close the doors, and watch the calls © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Different doors, one kind of call.

Follow each door to the end, and they arrive in the same room: an API call that looks legitimate. A real token, or real guest access, asking for data. No alarm goes off, because nothing was broken.

So closing the doors isn’t enough on its own. You also have to watch the calls: who’s exporting how much, from where, at what hour, through which app. That’s why chapter 14’s monitoring belongs to security as much as to reliability.

What It Means for the Integrations You Design

Section titled “What It Means for the Integrations You Design”

Every integration you design opens a door. Ask of each one:

  • Who could approve it, and could someone be talked into approving a copy of it? Only installed, known apps; only the people who need to approve them.
  • What its token can do, and for how long, if the partner holding it is broken into tomorrow: the narrowest scopes, rotation, an IP lock where it fits.
  • Whether anything answers without a login, and if so, exactly what the guest user can reach.
  • What’s sitting in your records that would make a theft worse: keys, passwords, tokens typed into a description field.
  • How you’d notice a normal-looking call that isn’t normal.

The rest of this chapter answers those, one door at a time.

Test knowledge. Know the three ways in from 2024 to 2026 and the control for each: social engineering into approving a connected app (or entering a device-flow code), closed by blocking uninstalled connected apps for ordinary users and restricting the device flow; a third-party app’s stolen OAuth tokens, limited by narrow scopes, IP restrictions, refresh token rotation and DPoP; over-permissive Experience Cloud guest users, closed by secure guest settings. In each, Salesforce states the platform wasn’t compromised: customer configuration and shared responsibility.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • Who may approve apps into the org, and the list of apps that are allowed.
  • For each integration’s token: its scopes, its IP lock, its lifetime and rotation, sized to what happens if the partner holding it is broken into.
  • Every place the org answers without a login, and what the guest user can reach there.
  • Which secrets must never sit in records, and the search that finds them if they do.
  • What gets watched: large exports, new app approvals, calls from unexpected places, and who’s told.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.