7 posts tagged with "Attack paths"

Open a public Experience Cloud page, a help centre or an application form, and watch the network tab. The page talks to Salesforce through one endpoint, /s/sfsites/aura, as the site's guest user. Nothing about that endpoint knows whether the request came from the site's own components or from a script. Whatever the guest user is allowed to read, anyone on the internet can read.

That is not a theory. In 2023 an independent researcher found hundreds of public Salesforce sites exposing records such as Social Security and bank account numbers to anonymous visitors. In March 2026 Salesforce warned customers that threat actors were mass-scanning public sites through that endpoint and extracting data, and said the cause was customer guest user configuration, not a platform flaw. This post walks the path a leak takes, hop by hop, and where each hop can be closed.

A security scan of a mature Salesforce org rarely comes back short. Hundreds of findings is normal: permissions that are broader than they need to be, Apex that runs without sharing, a session setting nobody has looked at since the org was created. Every one of them is technically true. Almost none of them tells you what to do on Monday morning.

The question a security team actually has is narrower: which of these lets someone reach data they should not?

The most damaging bug in web software is also the least interesting to describe. A request asks for record 1041. The server checks that you are logged in, loads record 1041 and returns it. It never asks whether record 1041 is yours. Change the number and you get your neighbour's.

That is broken object-level authorization, also called an insecure direct object reference or IDOR. The OWASP Top 10:2025 keeps broken access control at number one, and says that "100% of the applications tested were found to have some form of broken access control." Among the weaknesses it maps there is CWE-639, authorization bypass through a user-controlled key: the changed number.

Most Salesforce security reviews start with people: who is an administrator, who has MFA, who logged in from where. The data thefts of 2025 and 2026 mostly did not go through people's logins. They went through OAuth tokens, held by connected apps, acting as users who were never asked again.

The FBI's September 2025 alert explains why that matters: "Authorizing a malicious connected app bypasses many traditional defenses such as MFA, password resets and login monitoring, and because OAuth tokens are issued by Salesforce itself, activity coming from the malicious app can look like it's from a trusted integration." This post is about that surface: what a connected app is allowed to do, which settings decide how far a stolen token reaches, and how to review them.

Between late 2024 and the summer of 2026, attackers took customer records out of a long list of Salesforce orgs. The coverage made it sound like one breach of one platform. It was not. Salesforce said, case after case, that no vulnerability in its platform was involved, and the FBI's alert on the two main groups describes social engineering and stolen tokens, not an exploit.

What the attackers used instead was trust the orgs had already granted: to an employee, to an integration, or to the anonymous visitor of a public site. Read as a findings list, each org involved probably looked unremarkable. Read as attack paths, the same three shapes repeat. The FBI's September 2025 alert describes both 2025 campaigns in those terms: voice phishing that got a malicious connected app authorised, and OAuth tokens stolen from a third-party integration.

A Salesforce org is not a codebase you scan once before a release. It changes every week: a permission set edited in Setup, a connected app approved for a new integration, a sharing rule widened to unblock a deadline. None of that goes through a pull request, and most of it never reaches a repository.

Vulkro Cloud for Salesforce is a hosted workspace for keeping every org you run under continuous review. It is available by invitation today.

A Salesforce org rarely stands alone. Around it there is usually a small fleet of services nobody thinks of as "the Salesforce project": a Node service that receives webhooks and writes them into the org, a Python job that copies records into a warehouse, a Go API behind the customer portal, a Java service that holds the integration credentials. They are written by different teams, deployed by different pipelines and reviewed, if at all, by different tools.

An attacker does not see that boundary. If the first hop of the path is a route in the Node service and the last hop is a field in the org, a review that looks at only one side sees half a path and calls it two unrelated medium findings.